すべての「もの」を中央テーブルに格納する際の短所

Question

これを説明する用語があるかどうかはわかりませんが、コンテンツ管理システムはすべての種類のデータを最小限のプロパティメタデータはキー値のペアの形式で別のテーブルに格納されます。

たとえば、すべて（ブログ投稿、ページ、画像、イベントなど）は1つのテーブルに保存され、投稿と見なされます。

私は、これは我々が新しいプロジェクトをこのように設計し検討している抽象化と容易な拡張性

を可能にすることを理解しています。これはまさにCMSではありませんが、段階的にモジュールを追加していくつもりです。当初、コメントを掲示できる投稿と画像しか存在しないと言います。後で、コメント機能も持つビデオを追加することがあります。

このアプローチの欠点は何ですか？私たちのような要件のために働くでしょうか？

おかげ

Answer 1

シンプルさと拡張性は、実際に属性値の多くの場合、魅力的な側面であり、アプローチ（あなたが言うように）「物事の単一のテーブル」。

ありません100％右答えてください - あなたのパフォーマンス/スループットの目標と拡張性のニーズに応じて、この方法もあなたの役に立つかもしれません。

ただし、保存するデータの種類を知っている場合は、別個のエンティティを独自のテーブルにモデル化し、それに応じてデータを関連付けるのが通常です。 RDBMSは、このユースケースに対応するために何十年にも渡って設計され洗練されてきました。一般的なダンプ場としてテーブルを使用するだけでは、データを適切にモデル化する必然の必要性を遅らせることを除いて、さらに、すべてを1つのテーブルに沸騰させると、アプリケーション（たとえばレポート作成者など）が自分の「モデル内のモデル」と闘わなければならない場合は、アプリケーション自体の外にユーザーを強制します。あなたが最小の共通分母に沈むでしょう - もしあなたがタイプXについてのクエリを最適化し、その同じテーブルの中で型を持っていれば、それらはXを問い合わせる際のパフォーマンスに影響します。

ここでも、明確にするために、「すべてのものを1つのテーブルに」という名前/値スタイルのメタデータアプローチには明確な利点があります。私はそれを自分で使い、同様の理由でモデリングに反対しました。しかし、私が助言するのは、あなたが本当に必要な時代に自分自身を制限することです（つまり、必要なものの空間を正しくモデル化する前に、何かを実装する必要があります）。最も一般的には、私は複雑なシステムのプロトタイプを作成しているときにそれをやっていることがわかります。

Answer 2

この欠点は、メインテーブルがたくさんの読み込み（およびたくさんの書き込みも）になることです。

は、これがロック競合の多い、重い再インデックスがあることを意味など

あなたは、それほどメインない-一連のテーブルに「メインテーブル」を分割を検討して、このビットを軽減するために。

言って、あなたは（...プライベートスティッキー、アナウンス、一言ボックスのようなポストの特定のタイプのためのメタデータやサブテーブルによる可能性が洗練された）「投稿」のための1つのメインテーブルを持っています

画像のための一つのメインテーブル（おそらくgif、jpegなどで洗練された）

ビデオのための一つのメインテーブル...

これは、カスタムアプリケーションの場合（およびCMSまたはポータルフレームワークのように「無限に微調整できる」ように持っているものであることを意図していない）私は、この種を考えます（データが大量であることが予想される場合）より良いパフォーマンスを提供する可能性があります。

「例」コメントについて...まず、1つの巨大なテーブルにコメントを残しておくと、その中にすべてのタイプのアイテムを保持している場合と同様の問題が発生する可能性があります。 これは問題ではないと思われるが、明らかに、コメントを元のアイテムにリンクする一種の参照キー（もちろん、通常の外部キーは使用できない）を置くことができる。

これは、アイテムからコメントに行くときにはうまくいきます。コメントから元のアイテムに移動する必要がある場合は少し少なくなります。だから、あなたの問題のためにどんな種類の操作が頻繁に行われるかということとのトレードオフがあります。