0

プロジェクトを追跡するアプリケーションを作成する必要があります。そのため、ID、名前、所有者などの属性を持つプロジェクトがいくつかあります。各プロジェクトには、その下に多くのタスクがあります。各タスクには、ID、名前、完了ステータス、優先度、所有者などの属性があります。

このアプリケーション用の DB を設計するとき、2 つの可能な設計が頭に浮かびます。どっちのデザインがいいのかわからない。以下のデザインの中で、より優れたデザインを教えていただければ幸いです。一方のスコアが他方より優れている理由を忘れずにお知らせください。

ここにアプローチがあります。

アプローチ 1. DB に 2 つのテーブルを作成します。1 つはプロジェクト テーブル、もう 1 つはタスク テーブルです。タスク テーブルには、特定のタスクをその一部であるプロジェクトにリンクするプロジェクト ID の外部キーがあります。以下の他のアプローチに対するこのアプローチの基本的な差別化要因は、それがどのプロジェクトに属しているかに関係なく、すべてのタスクが 1 つのテーブルだけに格納され、その長さが無期限に増加し続けることです。

アプローチ 2. Project テーブルを 1 つ用意し、プロジェクトごとに、そのプロジェクトのタスクのみを含むテーブルを動的に作成します。したがって、プロジェクト テーブルの行と同じ数のタスク テーブルが存在します。動的に作成されたテーブルの名前に到達するアルゴリズムが存在する可能性があります。このロジックを使用して、クエリを実行するときに特定のテーブルの名前を取得できます。面倒に見えますが、このアプローチに見られる利点は、特定のプロジェクトのすべてのタスクが 1 つのテーブルだけにあり、その長さが制御不能になることはありません (少なくとも上記のケースほどではありません)。ただし、テーブルの数は無期限に増加し続ける可能性があります。

4

1 に答える 1

3

アプローチ 1 の方が優れています。プロジェクトごとにテーブルを作成する必要はありません。これはアンチノーマライゼーションです。テーブルは次のようになります。

(疑似コード)

CREATE TABLE project (
  projectId int NOT NULL PRIMARY KEY
  name varchar,
  owner varchar);

CREATE TABLE task (
  taskId int AUTO_INCREMENT PRIMARY KEY,
  projectId int NOT NULL,
  name varchar,
  completionStatus varchar,
  priority int,
  owner varchar,
  FOREIGN KEY projectId
    REFERENCES project.projectId)
于 2013-05-15T15:45:03.903 に答える