0

私は新しいフィールドを追加することができ、外部テーブル行が削除されたときに行を自動的に削除できるので、エンティティ属性値のものが好きですが、データ型を強制できないという事実は気に入らない。そして、選択クエリは複雑です。ダイナミックフィールドを格納するための適切なテーブル構造は何ですか?

属性ごとにテーブルを作成するより良い方法はありますか?

可能性のあるすべての属性を持つ非常に大きなテーブルを作成すると、ほとんどの行がほとんどの列にNULLを持つ場合でもこのテーブルは領域を占有しますか?

答えて

1

EAVモデルでは、複数の値フィールドを使用してデータ型を適用することができます。これは、タイプを指定するために別の列が必要であるため、さらに1つの値だけが満たされ、そのタイプに一致するように指定する追加の制約が必要なため、ややこしいことになります。

ほとんどのデータベースでは、チェック制約を使用してこれを処理できます。

さらに、単一の文字列値を使用して、チェック制約を使用して文字列の内容を適用できます。これはしばしば十分です。このような制約は、それらをサポートするデータベースで正規表現を有効に使用します。

あなたの2番目の質問については、各行は、エンティティ/属性列のスペースを占有します。 NULLの値がスペースを占有するかどうかは、データベースによって異なりますが、通常このスペースは小さくなります。

+0

ありがとうございます!私はより多くの検索を行い、別の方法を見つけました - サブタイプ - http://stackoverflow.com/questions/3579079/how-can-you-represent-inheritance-in-a-database/3579462スキーマの変更が必要ですが、少なくともすべてのテーブルで同じIDを保持できます。あなたはそれがeavの良い代替品だと思いますか? – thelolcat

+0

@thelolcat。 。 。よりよい解決策は、「要件」に依存します。 Postgresを使用している場合は、テーブルの継承も考慮する必要があります。 –

関連する問題