●データの入れ物
データベースには、様々な情報を格納できるように設計されています
データベースには、様々な情報が入れられるはずですが
設計されていない物は入らない・・・当たり前です。
今回、当社の方が情報が多く、それを新システムに連携する際に
入れるところが無い・・・・って事が分かっています
当社には、αとβと言う箱にそれぞれＡとＢと言う情報を格納しています
でも、新システムには、δという箱しかありません。
ただ、顧客によってαだけだったり、βだけだったりすることが多いので
我が上司は、当社システムのα、βに入っている情報は新システムのδに入力せよと指示
こんな感じですね
当社システムから新システムにデータを移送する場合は良いんですが
逆の場合は、どうすりゃいいの？って感じです
データの形態からも見分けることが出来ません。
同じような表現になることもあります
もっと悪いことには、両方のデータが存在するお客様もあります
この時点で新システムに移送することは不可能となります
いや、一つだけ方法があります
お客様に、新システムになったので今まで提供していたこのサービスは
今後、廃止しますです
●例えば住所録
もっと身近な例で伝えると、
ある住所録ソフトを使っているとします
その住所録ソフトは電話番号の入力欄はあるけれど、Ｆａｘ番号欄はありません。
あるとき、知り合いがｆａｘを購入したと・・でも固定電話は持っていません。
こまったあなたは、住所録の電話番号欄にＦａｘ番号を入力ししました。
そして、この知り合いは電話番号欄にｆａｘ番号が入力されていることを覚えておきます
さて、また知り合いが出来ました
その知り合いは、電話もｆａｘも持っていました。
お手上げですね
こういった状況が起こっているのです
●用途以外の仕様は
データベースにはいろいろなデータが格納できますが
冒頭にも言ったように、設計されたデータ以外のものを無理やり入れると
そのデータベースは汚れてしまいます。
当社では、格納が必要なデータがはっせいしたら
都度都度データベースに専用のフィールド（最初の方で箱と言っていました）を追加してきました
追加したらいいわけですよね
でも、親会社はそれをしてきませんでした
何故でしょうか？
それは、深く暗い闇の部分が覆い隠しています
●染みついたものは
でも、そのような昔から行ってきた、使いまわし
その文化はずっとそうしてきた人たちには染みついてしまっているのかも知れません
現在は、ベンダーさんがデータベースの構造を設計しています
これまで、フィールドの追加なんて日常茶飯事です
ただ、それわすると関連プログラム修正が必要なので費用追加となります
我が上司は、自分のデータベース設計をしょぼすぎるのを棚に上げて
これ以上フィールド追加して費用追加するのはヤバいと・・・
責任取れよー！
って心の中で叫んでいます
