1

与えられたテーブルtblProject。これには無数のプロパティがあります。たとえば、幅、高さなど。数十個。

モバイルデバイス用のプロジェクトの設定を指定できる新しいモジュールを追加します。これは1対1の関係であるため、すべてのモバイル設定をtblProjectに保存する必要があります。ただし、リストは膨大になり、プロパティ間にあいまいさが生じます（つまり、Mobile_widthがwidthと混同されないように、すべてのモバイルフィールドの前にMOBILEを付ける必要があります）。

モバイル設定を非正規化して別のテーブルに保存するのはどれほど悪いことですか？または、設定を保存するためのより良い方法はありますか？プロパティと扱いにくくなり、テーブルで変更/検索するのが困難になります。

4

2 に答える 2

2

@Alexander Sobolevの提案に応えて、私自身の提案を提供したいと思います。

@AlexanderSobolevはEAVモデルを提案しています。これは、エンティティのすべての値を取得するために複数回結合する必要があるため、パフォーマンスと複雑さが低下するため、最大限の柔軟性と引き換えになります。これらの問題を通常回避する方法は、すべてのエンティティメタデータをメモリ（つまりtblProperties）に保持して、実行時にそれに参加しないようにすることです。tblProjectPropertiesそして、ルートテーブルからCLOB（つまりXML）として値（つまり）を非正規化します。したがって、値テーブルはクエリと並べ替えにのみ使用し、実際にデータを取得するためには使用しません。また、通常は実際のエンティティをIDでキャッシュすることになるため、毎回逆シリアル化の費用をかける必要はありません。発生した問題は、エンティティとそのメタデータのキャッシュの無効化です。したがって、全体としては重要なアプローチです。

代わりに、ディスクリミネーター/タイプ列を使用して、データに応じて複数のテーブルを作成します。

create table properties (
    root_id int, 
    type_id int,
    height int
    width int
    ...etc...
)

root_idとの組み合わせを一意にtype_idしtype_idます。たとえば、モバイルを表します。この例では、別のルックアップテーブルを想定しています。

于 2011-02-14T14:49:44.367 に答える
1

他のテーブルにモバイルセクションを保存することに何も悪いことはありません。これはある程度の経済をもたらす可能性さえあります、これはこの情報がどれだけ使用されるかに依存します。

別のテーブルに保存することも、3つのテーブルを持つさらに複雑なバージョンを使用することもできます。1つはtblProject、1つはtblProperties、もう1つはtblProjectPropertiesです。

create table tblProperties (
id int autoincrement(1,1) not null,
prop_name nvarchar(32),
prop_description nvarchar(1024)
)

create table tblProjectProperties
(
   ProjectUid int not null,
   PropertyUid int not null,
   PropertyValue nvarchar(256)
)

外部キーtblProjectPropertiesを使用します。ProjectUid->tblProject.uidおよび外部キーtblProjectProperties.propertyUid->tblProperties.id

異なるプロパティを使用する異なるタイプのプロジェクトがある場合、これらの未使用のnullをすべて保存する必要はなく、特定のプロジェクトに本当に必要なプロパティのみを保存する必要があります。上記のスキーマは、ある程度の柔軟性を提供します。さまざまなプロジェクトタイプのビューをいくつか作成し、それを使用して、ユーザー選択での結合が多すぎないようにすることができます。

于 2011-02-14T12:53:58.857 に答える