10

テーブルの各フィールドの前に省略したテーブル名を付けていますか?

例：

Table: User

Fields:
user_id
user_name
user_password

それとも、フィールドに最小限の名前を付けますか?

Fields:
id
name
password

両方を使用したことがある場合、長期的にどの形式が最も役に立ったと思いますか?

編集：この質問には明確な答えがないようで、双方に良い点があります。しかし、私はあまりにも長い間質問を開いたままにしていたので、1 つの回答を承認済みとしてマークする時が来たのかもしれません。したがって、私は最も投票数の多いものを承認済みとしてマークしています。

4

14 に答える 14

35

そうしないでください。それは冗長であり、長期的にはフラストレーションにつながります。

これを適用できる唯一のフィールドは、id明らかuser_idにユーザーのIDであり、SQLでの結合の記述を簡素化するためです。しかし、私はそれさえしません。

于 2009-01-21T12:45:58.027 に答える
20

それを行うと、次のようなクエリを書くことになります。

SELECT user.user_name, user.user_password, user.user_firstname ...

それ以外の

SELECT user.name, user.password, user.firstname

IMOあなたの質問に対する答えは非常に明確です。

于 2009-01-21T12:50:59.157 に答える
10

もうそれをする必要はありませんし、本当にそうすべきではありません。saua が指摘した唯一の例外は、結合を明確にするための ID フィールドです。

フィールド名にテーブル名のプレフィックスを付けるという概念は、データベース全体の各フィールドが一意である必要があったレガシー システムの古い時代から来ています。

したがって、データベース全体の各フィールドに一意の名前を付ける必要があるレガシー システムを扱っている場合を除きます。それをしません。

于 2009-01-21T12:51:22.150 に答える
7

私はそれをしません。フィールドが属するテーブルの情報が必要な場合は、いつでもクエリを次のように記述できます。

select user.id, user.name from user where ...

しかし、何らかの理由でテーブルの 1 つの名前を変更することを決定したとします (おそらく「user」から「customer」に)。一貫性を保つために、すべてのフィールドの名前も変更する必要があります。

私の意見: それをすべき正当な理由はなく、そうすべきでない正当な理由がいくつかあります。

于 2009-01-21T12:54:04.907 に答える
4

列名にプレフィックスを付けることは良い習慣です。正式な（そしておそらく大規模な）データベースで作業していて、ISO 11179（特にデータ要素名の概念）に注意を払っている場合は、完全な3つ（または4つ）の部分名を次のように入力することをお勧めします。オブジェクト-プロパティ-表現用語。（4番目のオプション部分は修飾子です。）たとえば、「user_first_name」。そうすれば、データディクショナリとデータベーススキーマの間に一貫性があります。すでにコメントした理由により、小規模なデータベースではこれを行いませんが、複雑なスキーマでは、これによりエラーのリスクが軽減されます。

于 2009-01-21T14:49:18.980 に答える
3

また、通常は省略されたテーブルプレフィックスを使用しないため、アドバイスもしません。

ただし、私たちが行う状況が1つあります。それは、フィールドの予約です。

 e.g. OH_Reserve_Field_Alpha3 in table ORDER_HEADER

短い背景：私たちのデータベースには250以上のテーブルがあり、それらのほとんどに予約列を入れて、将来の機能の実装に使用します。ご想像のとおり、プレフィックスを付けないと、コード全体で意味がまったく異なるが同じ名前のReserve_Field_Alpha3が50個あることになります。今のようにすでに難しいですが、接頭辞がないともっと悪いでしょう。

于 2009-01-21T13:03:08.447 に答える
3

次のようなテーブル エイリアスを使用することをお勧めします。

SELECT 
    user.id,
    user.email, 
    user.firstname, 
    user.secondname,
    avatar.filename
FROM
    pain_in_the_butt_table_name user
LEFT JOIN
    table_with_the_avatars avatar
ON avatar.user_id = user.id

利点:

  • 選択したフィールドと、それらを取得するテーブルのわかりやすいリストを維持する

  • 長いテーブル名やわかりにくいテーブル名を入力することは避け、短くてわかりやすい名前に置き換えてください (テーブルの作成時に行っておく必要があります)。

  • 読み取り可能な結合を実行します（あなたの例は次のようになります：

LEFT JOIN table_with_the_avatars.user_id ON user.user_id = table_with_the_avatars.avatars_user_i

  • さらに短いエイリアスを作成します。私の例では、ユーザーの代わりに u を意味し、アバターの代わりに a を意味し、クエリを短縮します
于 2012-06-20T13:39:22.697 に答える
2

個人的には、「user」テーブルでは、私の列は「id」になります。

しかし、その列を指すさまざまなテーブルの外部キー列は、列「user_id」と呼びます。

だからあなたはこのようなものになるかもしれません：

select  *
from    order
        inner join user
            on user.id=order.user_id
于 2009-01-21T14:50:57.307 に答える
2

そのようにフィールドに名前を付けることは (最小限) OK ですが、主キーとキャプション/名前の場合です。一貫してすべての主キーに ID と名前を付け、名前に名前を付けると、クエリを構築すると余分なエイリアスに退化します。

select i.id as invoice_id

v.id as vendor_id, p.id as product_id, 
v.name as vendor, p.name as product, b.name as branch, c.name as parcel,

i.total_amount,
i.discount,
i.invoice_date

from invoice i
join product p on i.product_id = p.id
join vendor v on i.vendor_id = v.id
join branch b on i.branch_id = b.id
join parcel c on i.parcel_id = c.id

テーブルを結合してエンティティのキ​​ャプション/名前を表示することは例外ではなく標準であるため、主キーに完全な形式の名前を付け、キャプション/名前フィールドにはテーブル名と同じ名前を付けます。

create table product
(
product_id uuid not null, -- primary key
product text not null,
bar_code text not null default '',
rfid_code text  not null default '',
current_qty int default 0
);

create table vendor
(
vendor_id uuid not null, -- primary key
vendor text not null,
is_active boolean not null default true
);

create table branch
(
branch_id uuid not null, -- primary key
branch text not null,
sub_branch_of_id uuid,
current_sales money not null default 0,        
);

create table user
(
user_id uuid not null, -- primary key
user text not null,
password text not null default ''
);

したがって、クエリに余分なエイリアスはありません。

select i.invoice_id, p.product_id, v.vendor, p.product, b.branch, c.parcel,

i.total_amount,
i.discount,
i.invoice_date

from invoice i
join product p on o.product_code = p.product_code
join vendor v on o.vendor_code = v.vendor_code
join branch b on o.branch_code = b.branch_code
join parcel c on o.parcel_code = c.parcel_code
于 2009-01-21T13:54:45.550 に答える
2

フィールド「序数」をテーブルに追加するとき、接頭辞を追加したいので、JOINS の他のテーブルから序数フィールドにエイリアスを設定する必要はありません。JOINS に便利な場合もあります...他の利点を見たことがあるかどうかはわかりません。

MediaWiki (Wikipiedia ソフトウェア) はその規則を使用します。ソースをダウンロードします。プレフィックスは 2 文字に制限されています。

ただし、練習はお勧めしません。ほとんどのデータベースでは必要ありません。

于 2009-01-21T13:28:41.840 に答える
1

与えられたすべての理由から、これは良い考えではないと思います。さらに、クラス内のすべてのメソッドにクラス名のプレフィックスを付けていませんか? では、なぜデータベース オブジェクトに対して行うのでしょうか。

于 2009-01-21T13:21:33.073 に答える
0

それは素晴らしい実践です：

  1. 少なくともそれがどのドメインであるかで、すべてのフィールドが何を意味するかがわかります。amount（transactions、incomes）の意味を理解することはできません—xac_amountと である場合を除きinc_amountます。ほとんどのクエリツールは、フィールド名とともにエイリアスを出力しません。
  2. 確かに、テーブルエイリアスを使用できます。ただし、SQLはそれらを必要とせず、マーフィーの法則により、必要がない場合は使用されません。標準がないため、1人の開発者がxのエイリアスとして使用し transaction、別 の開発者が使用tranします。

実際、プレフィックスは強制的なテーブルエイリアスであるため、どのフィールドがどのテーブルに属しているかを簡単に確認できます。

于 2009-01-21T13:00:41.430 に答える
0

各テーブルに UNIQUE PREFIX を使用している場合は、

  • 結合にエイリアスを使用する必要はありません (自己結合を除く)
  • データベース内のすべての列の名前は一意である必要があります
  • 列名自体から（出力または選択クエリから）テーブルを簡単に識別できます
于 2016-05-03T05:01:28.697 に答える
0

プレフィックスバリアントは、書き込みに時間がかかり、多くのフィールドを持つ SQL ステートメントを読み取るのが難しくなります。

複数のテーブルから選択する場合でも、あいまいなフィールドの前にテーブル名を付ける必要がないという利点しかありません。しかし

SELECT user.name, image.name FROM user, image

とあまり変わらない

SELECT user_name, image_name FROM user, image

クエリにあいまいなフィールドがないことの利点は、列名を使用するたびにテーブル名を入力しなければならないというオーバーヘッドによってすぐに使い果たされます。

于 2009-01-21T12:55:52.953 に答える