0

このアプローチに関する提案が必要です。以下の例を参照してください。

私は以下のようなテーブル構造を持っています

data_jobtype
id, identifier (varchar), description (varchar), userid (int)

data_statustype
id, identifier (varchar), description (varchar), userid (int)

data_usertype
id, identifier (varchar), description (varchar), userid (int)

data_roletype
id, identifier (varchar), description (varchar), userid (int)

約 10 の同様のテーブルがあります。次に、別のアイデアがあり、次のような新しいテーブルを作成しました

data_types
id, identifier (varchar), description (varchar), userid (int), typetype (varchar)

このテーブルは上記のテーブルからすべてのデータを取得し、typetypeフィールドはそれがどのタイプのデータであるかを示します。例えば。typetype= 'jobtype' またはtypetype= 'roletype`

この 2 番目のアプローチは問題なく機能しますが、同じテーブルを 2 回参照して 2 つの異なるタイプの結合を作成するクエリを作成していたときに、typesクエリで単一のテーブルを複数回クエリする方が複数のテーブルよりも優れているかどうかを理解する必要があることに気付きました。クエリの例:

select u.*, dt.description usertype_desc, dt2.description roletype_desc
from users u 
left join data_types dt on dt.identifier = u.user_identifier and dt.typetype = 'usertype'
left join data_types dt2 on dt2.identifier = u.role_identifier and dt2.typetype = 'roletype'
Where u.status = 'live'

私が心配しているのはこのクエリだけではありません。プロジェクトはまだ初期の段階ですが、最終的には大きくなる予定ですので、今は基本的な構造を構築する時間があるので、正しく行っているかどうかについてコメントをいただければ幸いです。他のアプローチよりもどのアプローチをお勧めしますか?その理由は? ありがとう

4

2 に答える 2

1

結合条件で両方のタイプをリンクする方がはるかに簡単です。

left join data_types dt 
on dt.identifier = u.user_identifier and dt.typetype in ('usertype', 'roletype')

単一テーブルのアプローチにパフォーマンスへの影響があるとは思いません。問題は、より読みやすいクエリを作成する方法です。

于 2012-11-14T14:04:28.877 に答える
0

このアプローチは複雑な SQL を与えることになると思いますが、それは書くのがより難しく、さらに重要なことに長期にわたって維持するのがより困難です。

これらすべてのテーブルで同じ「もの」が複製されているのを見ない限り (その場合、「type_type」を結合テーブルに分離したい場合)、テーブルが保持するものを正確に記述しているテーブルに固執することをお勧めします。

また、時間の経過とともに、statustype に新しいフィールドを追加したり、jobtype に別のフィールドを追加したりする可能性があります。最終的には、これらのテーブル構造はますます類似しなくなります。

于 2012-11-14T14:38:05.613 に答える