最悪なのはデータ破損

データベースの設計がまずいとデータはあっという間に破損します。

コードの些細な不具合は修正ができますが、ぐちゃぐちゃに壊れてしまったデータは修正が出来ません。

だから、データは厳密に守らなければなりません。データを壊す不具合はいわゆる「ショー・ストッパー」 という不具合で、ショー・ストッパーがあるうちは製品は出荷してはいけません。

少しでもデータベースを勉強したひとならば、データベースには制約を設定できることを知っているはずです。

データベースの設計時に、「ここにはこのようなデータが入らなければならない」 という設定をしておくことが可能なのです。

だから、スキーマを正しく設計し、データベースの制約を用いれば、データベースに格納されたデータは一貫性がある、と断言できるようになります。 そうした機能を用いて、この最悪のトラブルを防がなければなりません。

事例 A: しかし、私は今までに何度もデータ破損が発生して大騒ぎしている現場に立ち会ったことがあります。

'A' か 'B' しか入らないはずのフィールドに 'X' が入っている。そんな状況です。

そんな時に彼らはきまって、「不具合が発生した。『データが悪いのか』『コードが悪いのか』分からない」 というのです。

それはデータベースに制約を設定すれば、完全に防げたはずの問題です。

データベースに制約条件さえ設定されていたら、一度でもそのコードパスを通るテストをしていれば自動的に検出できたはずの問題です。

そのデータベースを "設計" した彼の口からこんなことをききました。

「データベースとはただの箱だ。どんなデータでも入るようにするべきだ。それが柔軟性というものだ」

事例 B: また、あるときは私が正規化したテーブルを上司がそれを変更するように求めてきました。

Table1 に Table2 のプライマリキーとなる ID を格納する他に、その ID を用いて Table2 から参照可能なデータを Table1 にも格納しておくべきだ、という主張です。

私はデータ破損が発生する可能性を指摘したのですが (ID = 1 とともに ID = 2 のデータが格納されている状態が発生しうる)、彼は次のように強く主張し私は会社の上司の命令を聞かざるを得ませんでした。

「ユーザーがデータベースを見たときに、複数のテーブルを参照しないようでは、ユーザーの利便性が低下する。 だから、ひとつのテーブルに全てのデータが入るようにするべきだ」

事例 C: 上司が "設計" したデータベースについて、私は非常に単純な正規化が出来ていないことを指摘したことがあります。

するとその上司は、次のようにいい私に説教を始めました。

「正規化など必要ない。現実は教科書どおりにはいかないんだ！」

上司の勢いから、説得は不可能と判断したので私は引き下がりました。

１０分位して上司は私に聞いてきました。

「小山さん。ところで、さっきの『正規化』ってなに？」

誤りを指摘したことに腹を立て、私の主張を受け入れられなかっただけではなく、そもそも何もわかってはいなかったのです。

無論、上記の事例は全てデータベースに対する理解が不足していることから発生する誤りです。

あなたのプログラムで何が重要であるか考えれば、ユーザーのデータを守ることをが非常に重要である場合がほとんどでしょう。

そうした優先順位をしっかり考えて正しく設計したいものです。

また、私のような目にあい、やる気をそがれたことのあるあなた。

こんなことは、よくある話のようです。

でも、あなたが正しいですよ。次のプロジェクトではまた正しいことを主張しましょう。