3

ここでデータベース設計の専門家からの提案が必要です。

  1. 1つのテーブル（欠陥）に約6つの外部キーがあり、それらはすべてユーザーテーブルの主キーを指しています。それは次のようなものです：

    defect (.....,assigned_to,created_by,updated_by,closed_by...)

    欠陥に関する情報を取得したい場合は、6つの結合を行うことができます。それを行うためのより良い方法はありますか？

  2. もう1つはstates、ユーザー定義の値のセットの1つを格納できるテーブルがあることです。欠陥テーブルとタスクテーブルがあり、これらのテーブルの両方で共通の状態テーブル（New、In Progressなど）を共有したいと思います。だから私は作成しました：

    • task (.....,state_id,imp_id,.....)
    • defect(.....,state_id,imp_id,...)
    • state(state_id,state_name,...)
    • importance(imp_id,imp_name,...)

重要度（通常、緊急など）、優先度などの状態とともに、このような共通の属性が多数あります。それらすべてに対して、同じテーブルを使用したいと思います。タスクと欠陥を区別するために、各テーブルに1つのフラグを保持しています。そのような場合の最良の解決策は何ですか？

誰かが健康領域でこのアプリケーションを使用している場合、彼らは彼らの欠陥またはタスクに異なるタイプ、状態、重要性を割り当てたいと思っています。さらに、ユーザーがプロジェクトを選択すると、構成パラメーターセクションの下にすべてのタイプ、状態などが表示されます。

4

2 に答える 2

6

1..。

これには本質的に何も問題はありません。可能なユーザーの「役割」が厳密に決定されており、変更される可能性が低い場合は、実際、これが推奨される方法です。Cが一定であるC：M関係を効果的にモデル化しています。

一方、役割が変更される可能性がある場合（たとえば、欠陥に新しい「ライフサイクルフェーズ」を動的に追加できる必要がある場合）、真のM：N関係をモデル化するリンク（別名ジャンクション）テーブルは、正当化される。このようなもの：

ここに画像の説明を入力してください

ところで、JOINにはコストがかかりますが、それだけで余裕がないわけではありません。また、常にすべてのJOINが必要なわけではない場合もあります。現在必要な情報を取得し、他の情報を除外するJOINを実行するだけです。いずれの場合も、実際のパフォーマンスの問題があるかどうかを判断するために、現実的な量のデータを測定することをお勧めします。

2..。

共通フィールドが多数ある場合は、継承1を使用して、共通フィールドと外部キーの繰り返しを最小限に抑えることができます。例えば：

ここに画像の説明を入力してください

このモデルでは、各「属性」テーブル（stateおよびなど）は、と1回だけimportance接続され、それを介して、およびなどの「継承された」テーブルのそれぞれに接続されます。追加する「継承された」テーブルの数に関係なく、「属性」テーブルごとに1つの接続しかありません。basedefecttask

このモデルは、基本的に「属性」FKの急増を防ぎますが、との管理がやや面倒にdefectsなりtasksます（現在、「共通」部分と「特定」部分に分割されているため）。これが古いデザインよりも良いバランスであるかどうかはあなたが決めることです...

1別名。カテゴリ、サブクラス、一般化階層など。

于 2012-06-29T09:58:13.403 に答える
1

最初の問題では、欠陥テーブルを分解して、作成、更新、割り当てなどのトランザクションの履歴を格納する「行」テーブルを作成する方がよいように思われます。

これには、より柔軟であるという利点があります。欠陥は、更新されて複数の人に割り当てられた、再開されたなどの履歴をより簡単に追跡でき、時間の経過に伴う複数の更新が明確に示されます。

欠陥の一般的なグローバル状態（特に、ステータス、優先度など、特にこれらの状態の変化を追跡する必要がない場合）を格納する欠陥テーブルがまだあり、一連の状態があります。 *defect_lines *。それぞれに欠陥を指す外部キーとユーザーを指す別の外部キーがあり、タイプフィールドは「作成」、「更新」などであるかどうかを示します。

例えば。

defect ( id, priority, status )
defect_line ( defect_id, timestamp, type, user, comment )

作成に問題がないという仮定に応じて、defect_id、timestamp、およびuserがdefect_lineの主キーになる可能性があります。

2番目の問題については、少なくともあなたが提供した情報では、それらはすべて同じプロパティを共有しているようです-したがって、基本的に同じものであり、異なるタイプのフラグ（「タスク」または「欠陥」）があります。同じテーブルにありますか？

私はおそらく、すべての欠陥をタスク（「修正すべきもの」）と見なすことができるという仮定の下でこのタスクを呼び出すでしょうが、すべてのタスクは欠陥ではありません-しかし、これはすべて現在のセマンティクスです。

ただし、個別の非共有プロパティがある場合は、タスク/欠陥の共有プロパティをテーブルに、およびそれぞれに固有のプロパティのテーブルを保持できる場合がありますが、それでも可能である可能性があります。同じ「ライン」詳細構造を共有します。これは、部分的に正規化と使いやすさの間の決定になります。これを複数のテーブルにまとめるよりも、ほぼ同じプロパティを持つ2つのテーブルを使用する方が簡単な場合があります。

于 2012-06-29T03:24:13.390 に答える