3

これはデータベースの設計に関する質問です。

ユーザーテーブルとチームテーブルがあります

User { ID, UserName, FirstName }

Team { ID, TeamName } 現在、ユーザーは 1 つのチームにのみ参加できることが決定されましたが、DBA は、ユーザーが複数のチームに参加できる可能性があると考えており (未来的な要件の可能性があります)、UserTeam テーブルを作成して、制限を実装するよう求めています。コード？

UserTeam { User_ID, Team_ID }

コーディング中に不必要に問題が発生し、データベース テーブルが現在の要件に従って制約されていないため、ブリッジ テーブルを削除し、ユーザー テーブルに teamID を含めて、後でユーザーが複数のチームの一部になることを心配する必要があります。

User { ID, UserName, FirstName, TeamID }

要件が本当に顧客からのものである場合、私の議論は理にかなっていて、後で設計を変更すると思いますか?

それとも、一般的な未来的なデザインに固執し、ユーザーをコード内の複数のチームに制限するのが良いでしょうか?

私の主張は、要件に一致する場合はシンプルに保つことです。* 制約は db テーブルに組み込まれています。※今後、必要に応じて変更する場合があります。

4

2 に答える 2

2

ヤグニ。この柔軟性が必要であると考えるやむを得ない理由がない限り、まだ気にする必要はありません。

ここにリトマス試験紙があります。あなたは正直に言って、これをファーストクラスの機能にすることに全力を尽くしていますか? ユーザーが複数のチームに所属できることを想定して、ユーザー インターフェイス、フォーム、バリデーター、および管理機能を構築しますか? それとも、中途半端に機能をデータベースに入れるだけで、コードには存在しないふりをさせるつもりですか? 私はこの立場にいましたが、おそらく後者を実行しているでしょう。その場合、実際には時間を節約できていません。また、この機能が本当に必要になり、忘れてしまった場合は、さらに多くの時間を無駄にしている可能性があります。どれだけ存在するかです。

それはただのコードです。いつでももっと書くことができますが、絶対に必要な場合に限ります。

しかし、その「名」欄については……

于 2013-01-16T07:24:37.173 に答える
1

私は SQL データベースの設計者であり、アプリケーション プログラマーでもあります。

今、あなたはこのようなものを持っています。

create table users (
  user_id integer primary key,
  user_name varchar(35) not null unique
);

create table teams (
  team_id integer primary key,
  team_name varchar(35) not null unique
);

次の表は、各ユーザーが最大 1 つのチームのメンバーになることができるという現在の要件を実装しています。(私は、一部のユーザーはどのチームのメンバーでもない可能性があると想定しています。おそらく、雇用されてから出勤するまでの間だけです。)

create table team_members (
  user_id integer primary key references users (user_id),
  team_id integer not null references teams (team_id)
);

その要件が変わり、ユーザーが複数のチームのメンバーになることを許可する必要がある場合は、主キーを {user_id} から {user_id, team_id} に変更するだけです。アプリケーション コードを変更する必要はまったくありません。(ただし、以下の「意見の相違を文書化する」を参照してください。)

このようにチームメンバーシップを実装したいとします。

create table users (
  user_id integer primary key,
  user_name varchar(35) not null unique,
  team_id integer null references teams (team_id)
);

その場合でも、チーム メンバー ビューを実装し、アプリケーション コードでそのビューを使用する必要があります。アプリケーションによっては、これを更新可能なビューにする必要がある場合があります。

create view team_members as 
select user_id, team_id 
from users;

これは、チーム メンバーシップをユーザーのテーブルに入れると、そのテーブルの述語が破損するためです。ユーザーのテーブルではなくなりました。これは、ユーザーとそのチーム メンバーシップのテーブルです。したがって、「ユーザー」という名前は正確ではありません。「users_and_team_membership」のような名前が必要です。(データのリレーショナル モデルと SQL の両方で、テーブル名は変数の名前であり、デフォルトではデータベースのパブリック API の一部です。ここでの原則は、「悪いコードにコメントしないでください。書き直してください。 "）

しかし、テーブル名を修正するか、紛らわしい「users」という名前のままにしておくと、1 つの混乱が 2 つになるだけです。「2」。1) 1 つのテーブルに 2 つの異なる種類のデータが格納されているため、2) 正確な名前を使用してテーブル "users" を失うか、誤解を招くような名前を使用してテーブル "users" を保持しているためです。

意見の相違を文書化する

また、この意見の相違を文書化して、アプリケーション プログラマーが間違ったことをするのを防ぐ必要があります。「ユーザーが 1 つのチームだけのメンバーであると仮定することは、チェックされていない実行時エラーです」のようなステートメントで十分です。

YAGNI は、データベースの設計と開発において、アプリケーション開発における YAGNI の意味とまったく同じ意味を持っているわけではありません。アプリケーション開発者は自分のコードを見て、1 つのデータベースを確認します。データベース設計者はデータベースを調べ、何十年にもわたって数十の異なる言語で書かれた何百ものプログラムを見て、不適切に書かれたパブリック API のコストを計算します。不適切なパブリック API を修正するには、何百ものプログラムの変更が必要になる場合があります。それは大金です。たくさんのお金。

于 2013-01-16T13:05:59.860 に答える