0

これが私が今いる場所です。タスク、プロジェクト、機会、および task_xref の 4 つのテーブルがあります。プロジェクト テーブルと商談テーブルはそれぞれ、タスクと 1 対多の関係にあります。それらの関係を task_xref に保存しています。各テーブルのスキーマは次のようになります (簡略化)。

task
----
id(pk)
name

project
-------
id(pk)
name
...

opportunity
-----------
id(pk)
name
...

task_xref
---------
task_id(task id)
fkey(other table id)

プロジェクトと商談のキーが同じ (GUID) ではないため、商談がプロジェクトのタスクを取得できないなどと想定します。これは、タスクとプロジェクト、機会 (または将来タスクの関係が必要になる可能性のあるその他のテーブル) の間の関係を維持するための 1 つの外部参照テーブルである表面上でうまく機能します。

私の現在のジレンマは双方向性です。個々のプロジェクトまたは機会のすべてのタスクを取得しようとしている場合、問題ありません。タスクを引き戻しているときに、関連するプロジェクトまたは機会の名前を知りたい場合、それはできません。関連する fkey がプロジェクトなのか機会なのかを知る方法がありません。将来的には、タスク関係を持つ他のテーブルを作成する予定です。現在は 2 つのテーブルがありますが、将来はさらに多くのテーブルが存在する可能性があります。

これまでに考えた解決策は次のとおりです。 1) ペアごとに個別の xref テーブル (例: task_project_xref、task_opportunity_xref...) 短所: 各 xref テーブルに対してクエリを実行して、タスクの関係を探す必要があります。

2) 親テーブルを指すための task_xref の 3 番目の列

3) プロジェクト、機会の主キーを識別可能な方法 (例: proj1、proj2、proj3、opp1、opp2、opp3) で保存し、fkey の短所を見て、タスクがどのテーブルに関連しているかを判断できるようにします。 m プロジェクトと機会の主キーを魔法のようにして、単一のレコードの単なる識別子ではなく、より多くの意味を吹き込みます (考えすぎかもしれません)。

私の質問はこれです: 私が見落としている他の解決策はありますか? 他のソリューションよりも優れている/劣っているソリューションはどれですか?

可能であれば結合を制限し、パフォーマンスを可能な限り維持しようとしています。また、コード内でデータを結合することが物事を簡素化するのに役立つのであれば、反対しません。

私は PHP と MySQL を使用しています (現在 MyISAM テーブルを使用していますが、理由があれば INNODB を使用します)。

4

2 に答える 2

0

task_xrefに個別のproject_idフィールドとopportunity_idフィールドがある場合、SQL結合はより適切になります。クエリは簡単なので、これは良い方法です。また、どの外部キーがnullでないかを確認するだけで、それがどのタイプのタスクであるかを簡単に判断できます。また、効率的です。タスクに参加する場合、プロジェクトと機会の構造が異なることは間違いないため、2つのクエリが必要です。そのため、結果を取得することはできませunionん。

于 2011-05-15T02:01:52.273 に答える
0

コンセプトごとに個別の外部参照テーブルを用意することを好みます。このようにして、概念からそのタスクへの関係を維持しやすくなり、他の概念のタスクへの関係から切り離すことができます。

デザイン内のテーブルにタスクを含めることができる場合は、関連するすべての概念に対して 1 つの xref を使用することをお勧めします。その場合は、タスクの親であるオブジェクトの種類を示す追加の列を追加するだけです。

于 2011-05-15T03:14:11.273 に答える