1


1

整合性を維持するには?

整合性を維持するために、どのようにテーブルを作成するのですか?

tblUserProfile

UserId
EyeColorId
HairColorId
RelationShipStatusId

etc.

EyeColorIdなどのこれらの各値には、Brown、Black、Yellow、Greenなどの値のセットがあります。 同様に、HairColorIdには黒、金髪、深紅など、RelationShipStatusIdには離婚、既婚、独身などがあります。 これらのそれぞれに異なるテーブルを作成する必要がありますか? like

tblEyeColor

EyeColorId
EyeColorCode

それから:-

tblHairColor

HairColorId
HairColorCode

同様にテーブルを作成し続けますか? このようなテーブルは多数あります(約20〜25)。 これらのテーブルを作成し続け、それらを結合すると、パフォーマンスが著しく低下します。 この種の列挙値をどのように維持しますか? チェック制約を保持する必要がありますか、またはテーブルを作成し続ける必要がありますか?

3 Answer


4


Colorは、髪と目両方が使用できる単一のテーブルのように見えます。 誰も金髪の目や青い髪を持つべきではないという事実を徹底することは、あなたの誠実さにとってどれほど重要ですか?

一部の人々は、ID、グループ、値、および各行の説明を含む単一のルックアップテーブルのアイデアを採用しています。 idとgroupが主キーになるため、BLONDEの髪の色として髪のid = 1とgroup = 1、HAZELの目の色として目のid = 1とgroup = 2になります。

他の人はこれを貧弱な非正規化された設計だと非難するでしょう。

特定のクエリの数が大きくなった場合にのみ、結合の速度が低下します。

私のアドバイスは、パフォーマンスが低いことを示唆するデータが得られるまで、正規化された設計を行うことです。 その場合は、アプリのプロファイルを作成して問題の場所を見つけ、適切にリファクタリングまたは非正規化します。

インデックス作成は、これらのJOINよりもパフォーマンスに大きな影響を与えると思います。 あなたはそれをサポートするためのデータなしで時期尚早の最適化の有罪かもしれません。


2


オプションの数が「固定」されている場合、テーブルを作成する必要はありません。テーブルで代わりに「Enum」タイプを使用できます。 e.g. 「EyeColor」列は「Black、Brown、Blue」の列挙型になります

しかし、私は緑色の目を持つ人を見たことがありません。 LOL


1


そう、伝統的な方法です。

最新のRDBMSは、これらのルックアップのような小さなテーブルを長期間キャッシュします。これにより、潜在的なマルチ結合の問題が軽減されます。

また、アプリケーションにすべてのルックアップテーブルをプリロードし、データベースにアクセスする前に、コード内で列挙型をIDに逆変換することもできます。 これにより、クエリで結合する必要がなくなります。