無駄にする時間がたくさんあり、情報がエンティティとしてではなくINT、VARCHAR、DATE、TEXT、 などのタイプを表す個別の相互に関連するテーブルに格納されるデータベースを作成することにしたとします。
誰もデータベース構造を設計する必要がないということは、それはとても革命的なことです.
では、なぜこれは悪い設計なのでしょうか? これはどのような原則に反していますか? リレーショナル データベースの実用的な観点から、どのような問題が発生する可能性がありますか?
PS: これは学習演習用です。
データ型に基づいてテーブルからフィールドを分離しないのはなぜですか? 理由は 2 つあります。1 つは哲学的なもので、もう 1 つは実際的なものです。
適切に正規化されたデータベースには、それぞれのテーブルが必要であり、その特定の「もの」に固有のすべてのフィールドを持ち、異なるものに対して異なるテーブルがあります。CarCollectionDatabase で特定の車のメーカー、モデル、色、走行距離、製造日、および購入日を見つける唯一の方法が、データ型で区切られた 3 つのテーブルの意味のないキーを結合することである場合、データベースの発見可能性はほとんどゼロであり、本当の結束はありません。
そのようなデータベースを設計した場合、クエリを作成してステートメントをデバッグするのは非常に面倒です。これが、そもそもリレーショナル データベースを使用する理由の一種です。
（そして、実際には、クエリの作成が非常に難しくなります。）
私がこれまでに見たすべてのデータベース エンジンまたはデータ ストレージ メカニズムは、そのレベルの抽象化で使用することを意図したものではありません。どのようなエンジンを持っていたとしても、フィールドを使用してデータ設計を本質的に 2 倍にすることを回避する方法がわかりません。また、行数が 5 倍になると、インデックスのサイズが大幅に増加し、数百万行になるとインデックスが実際には役に立たなくなるほどになります。
そのようなデータベースを設計しようとすると、頭痛の種を気にしなくても、パフォーマンスが低下することがわかります。20 個のフィールドを持つ 1,000,000 行の代わりに、同じ数のフィールドを持つ 1 つのテーブルと、それぞれ 1,000,000 以上のエントリを持つ 5 ～ 6 個のテーブルが追加されます。また、それを最適化したとしても、インデックスは大きくなり、大きなインデックスの実行は遅くなります。
もちろん、これら 2 つは、実際にデータベースについて話している場合にのみ適用されます。たとえば、アプリケーションがある種のテキスト ファイル (JSON、XML など) にシリアライズできず、データベースに書き込めないという理由はありません。
また、アプリケーションで SQL データを格納する必要があるからといって、すべてを格納する必要がある、または同種の汎用テーブルを使用できないというわけではありません。ユーザーが独自の「テーブル」を定義できるようにするAccessのようなアプリケーションは、各フィールドを個別の行に保持することができます...ただし、その場合、データベースのTHINGSはそれらのテーブルとそのフィールドになります。(そして、ネイティブに作成されたデータベースほど高速には実行されません。)