3

次のテーブルがあるとしましょう:CustomerとStaff.

Customer (CusID, CusName, CusAddres, CusGender)
Staff (StaID, StaName, StaAddress, StaGender)

対

Customer(ID, Name, Address, Gender)
Staff(ID, Name, Address, Gender)

好まれるデザインとその理由は?

4

5 に答える 5

5

SQL はドメイン名の整合性と呼ばれる概念を採用しています。これは、オブジェクトの名前がそのコンテナーによって指定されたスコープを持つことを意味します。

列名は一意である必要がありますが、列を含むテーブルのコンテキスト内でのみです。テーブル名は一意である必要がありますが、テーブルなどを含むスキーマのコンテキスト内でのみです。

列をクエリするときは、関心のあるスキーマ、テーブル、および列を参照する必要があります。クエリが非常に単純で 1 つのテーブルのみを参照する場合を除き、テーブル名を直接参照するか、Customer.ID や Customer C の C.ID などのエイリアスを使用して参照する必要があります。

最初のオプションは、1960 年代と 70 年代に古い ISAM データベースや COBOL などの言語に適用された、すべての列名の一意性に関する技術的要件への逆戻りです。これは、1980 年代に正当な理由もなく dBase に引きずり込まれ、リレーショナル DBMS およびオブジェクト DBMS の時代に至るまで慣習として定着しました。 この時代遅れの慣習に抵抗してください。

2 番目のアプローチは、はるかに単純で読みやすいものです。単純で読みやすいコードは、書きやすく、保守も容易です。

于 2012-08-01T13:09:20.197 に答える
2

Keys are "propagated" down foreign keys, so it's useful if they keep their names constant in all the resulting "copies". It just makes the database schema clearer: you don't have to look into FK definition1 to see where a particular field came from - you can do that by just glancing at its name.

On the other hand, non-key fields are not propagated and there is no particular reason to keep their names unique outside their respective tables.

So, I'd recommend a hybrid approach:

  • Prefix key field names to keep them unique among all tables and avoid any need for renaming propagated fields.
  • Don't prefix non-key field names to keep them shorter, even though this might lead to some name repetition in different tables.

For example:

Customer (CustomerID, Name, Addres, Gender)
Staff (StaffID, Name, Address, Gender)

And if you happen to have a junction table between the two2, it'll look like this...

CustomerStaff(CustomerID PK FK1, StaffID PK FK2)

...so no need for renames (that would be necessary if both parent keys were named ID) and it's immediately clear where CustomerID and StaffID came from. Also, I personally don't like shortening table names in the prefix (hence CustomerID and not CusID), as this makes naming even more "mechanical" and predictable.

1 Potentially multiple levels of them!

2 Just an example. Whether it makes sense is another matter.

于 2012-08-01T15:19:10.927 に答える
2

ID は SQL アンチパターンです (http://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557/ref=sr_1_1?s=books&ie=UTF8&qid=1343835938&sr=1-1&keywords=sql+antipatterns) 、列 ID を指定しないでください。私は使うだろう：

Customer(CustomerID, Name, Address, Gender) 
Staff(StaffID, Name, Address, Gender)
于 2012-08-01T15:46:00.797 に答える
1

2番目のオプションの方が良いと思います。テーブル名を変更する場合は、すべての列の名前を変更する必要はありません。また、SELECTステートメントを作成するときは、通常、エイリアスを使用します（ "select sta.name、sta.adress from staff sta ..."）一般に、疑問がある場合は、常により単純なソリューションを選択してください。

于 2012-08-01T10:12:57.940 に答える
0

すべての業界には独自の基準があります。これらの両方のデザインスタイルは正常です。最初のものを使用することをお勧めします。

Customer(CusID, CusName, CusAddres, CusGender)
Staff(StaID, StaName, StaAddress, StaGender)

CustomertoCusやStafftoのようなテーブル名記号を使用しているためSta。これは、プロジェクトのメンテナンスに役立ちます。

一部の組織では、データ型、データ型にも使用vchしています。VARCHARintINT

好き

Customer(intCusID, vchCusName, vchCusAddres, vchCusGender)
Staff(intStaID, vchStaName, vchStaAddress, vchStaGender)
于 2012-08-01T10:06:33.520 に答える