2

いくつかのエンティティに関連するいくつかのレビュー フラグを保存する必要があります。各レビュー フラグは、1 つのエンティティ プロパティ グループにのみ関連付けることができます。たとえば、テーブルParentsにはParentsStatusフラグがあり、テーブルChildrenには一連のChildrenStatusフラグがあります。

現在の設計案では、3 つのテーブルがあります。

  • ReviewTypes: フラグと関連するプロパティを格納します。
  • ReviewPositions: フラグが持つことができる値を格納します。
  • Reviews: トランザクション データ、実際のレビューを保存します。これは、UsersToFlags: Flags in a database rows, best practice のようなものです。

問題は、テーブルを持つ必要はなく、Reviewsこの実際のレビュー データを各エンティティに保存する方がよいというプッシュバックを受けていることです。たとえば、追加の列Parentsを holdに追加しますParentsStatus。彼らは、それがより単純なソリューションであり、データを分離することはアウトシナリオにとって「やり過ぎ」であると感じています.

これは、新しいレビュー フラグを追加するたびに、コア エンティティ テーブルを更新してそのフラグを保持する必要があることを意味するため、この考えは好きではありません。

スペースは問題ありません。

人々は強い意見を持っていますか？

編集：

このコメントは、3 つの回答に適用されます。コンセンサスは、リレーショナル アプローチが最適であるということですが、EAV データベース モデルを理解するための非常に基本的な読み物として、EAV モデルについてもう少し読む必要があると思います。およびその関連リンクは、非常に単純ではないようであり、穴を掘りたくありません。ワイルドプラッサーに感謝します。もう少し読み進めたら折り返します。

4

3 に答える 3

3

そうそう。あなたがそれを強化したいと思うまで、彼らのアイデアはより単純です。スキームを考えると、エンティティごとに 2 つのレビューが必要な場合はどうなるかを提案しています。メモ/注釈など、他のものを添付したい場合はどうなりますか。彼らのアイデアがどれだけインフレータブル ダーツボードであるかがわかったら、もっと便利なダーツボードに移行するにはどうすればよいでしょうか? 言うまでもなく、列名が「_Status」で終わるなどの壊れやすいゴミを使用して、ステータスフィールドを識別する何らかの方法が必要です。または、どこかにハードコーディングする必要があります。

適切に行うことは、それほど手間がかからず、複雑でもありません。実際、多くの点でより単純であり、はるかに少ないコストで不可避の変更に対処できます。

于 2012-06-06T13:47:51.543 に答える
2

正規化は、時期尚早の最適化よりも常に望ましいです。

于 2012-06-06T14:19:42.820 に答える
1

私がレビュー テーブルを別にするのが好きな理由の 1 つは、まだ表示したくない変更を保持し (レビューも承認もされていないため)、新しいデータが承認されるまで古いデータを維持できることです。あなたの状況がそれを必要とするかどうかはわかりません。

変更を表示する場合に備えて、将来のプログラミングを簡単にするために、古いデータと新しいデータを表示するビューを作成できます。

于 2012-06-06T14:15:38.053 に答える