動的データベーススキーマ [closed] 質問する

Question

あなたが提案していることは目新しいものではありません。多くの人がそれを試してきましたが、ほとんどの人が「無限の」柔軟性を追い求めて、結局はそれよりもはるかに少ないものしか得られないことに気付きました。これはデータベース設計の「ゴキブリホテル」です。データは入っても、それを取り出すことはほとんど不可能です。どんな種類の制約に対してもコードを書くことを概念化してみれば、私の言っていることが分かるでしょう。

最終的に、デバッグやメンテナンスがはるかに難しくなり、データの一貫性の問題が山積するシステムになるのが一般的です。これはいつも多くの場合、結局はそうなってしまいます。ほとんどの場合、プログラマーがこの大惨事が起こることを予期せず、防御的なコードを作成できないためです。また、多くの場合、「無限の」柔軟性は実際にはそれほど必要ではありません。開発チームが「ここにどのようなデータを入れるのかまったくわからないので、何でも入れさせてください」という仕様を受け取ると、非常に嫌な「匂い」がします...そして、エンドユーザーは、使用できる定義済みの属性タイプがあれば十分です (一般的な電話番号をコーディングし、任意の番号を作成できるようにします。これは、適切に標準化されたシステムでは簡単なことであり、柔軟性と整合性を維持します)。

非常に優秀な開発チームがあり、深く認識しているこの設計で克服しなければならない問題のいくつかを除けば、うまく設計された、それほどバグのないシステムをうまくコーディングすることができます。ほとんどの場合。

しかし、なぜ最初からそんなに不利な状況から始めるのでしょうか?

信じられないですか? Google で「One True Lookup Table」または「single table design」を検索してください。良い結果がいくつか見つかります:http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:10678084117056

http://thedailywtf.com/Comments/Tom_Kyte_on_The_Ultimate_Extensibility.aspx?pg=3

http://www.dbazine.com/ofinterest/oi-articles/celko22

http://thedailywtf.com/Comments/The_Inner-Platform_Effect.aspx?pg=2

Answer 1

あなたが提案していることは目新しいものではありません。多くの人がそれを試してきましたが、ほとんどの人が「無限の」柔軟性を追い求めて、結局はそれよりもはるかに少ないものしか得られないことに気付きました。これはデータベース設計の「ゴキブリホテル」です。データは入っても、それを取り出すことはほとんど不可能です。どんな種類の制約に対してもコードを書くことを概念化してみれば、私の言っていることが分かるでしょう。