3

最近のいくつかの質問では、列に名前を付けるための戦略について説明していますが、列名に外部キーと主キーの概念を埋め込むという概念を発見したことに、私はかなり驚きました。あれは

select t1.col_a, t1.col_b, t2.col_z
from t1 inner join t2 on t1.id_foo_pk = t2.id_foo_fk

この種のスキームを使用するデータベースシステムで作業したことは一度もないことを告白する必要があります。その利点は何でしょうか。私の見方では、システムのN個のプリンシパルテーブルを学習したら、それらのテーブルを使用して数桁多くのリクエストを記述します。

開発で生産性を高めるには、どのテーブルが重要なテーブルであり、どのテーブルが単純な支流であるかを学ぶ必要があります。かなりの数の列名をメモリにコミットする必要があります。そして、基本的なタスクの1つは、2つのテーブルを結合することです。学習の労力を減らすために行う最も簡単な方法は、両方のテーブルで列名が同じであることを確認することです。

select t1.col_a, t1.col_b, t2.col_z
from t1 inner join t2 on t1.id_foo = t2.id_foo

開発者として、どの列が主キーであり、どの列が外部であり、どの列が何でもないことについて、それほど気にする必要はないと思います。興味があれば、スキーマを確認するのは簡単です。ランダムに見るとき

tx inner join ty on tx.id_bar = ty.id_bar

...どれが外部キーであるかを知ることはそれほど重要ですか？外部キーは、データベースエンジン自体にとってのみ重要であり、参照整合性を確保し、更新および削除中に正しいことを実行できるようにします。

ここでどのような問題が解決されていますか？（私はこれが議論への招待であることを知っています、そしてそうすることを遠慮なくしてください。しかし同時に、私は本当に何かを逃しているかもしれないという点で答えを探しています）。

4

6 に答える 6

7

仰るとおりです。この情報を列名に入れると、Windowsの初期のくだらないハンガリアン記法のばかげたものになります。

于 2008-10-17T22:31:28.253 に答える
6

子テーブルの外部キー列は、親テーブルの主キー列と同じ名前にする必要があることに同意します。これにより、次のような構文が許可されることに注意してください。

SELECT * FROM foo JOIN bar USING (foo_id);

USING キーワードは、両方のテーブルに同じ名前の列が存在し、等結合が必要であることを前提としています。これをより冗長なものの省略形として利用できると便利です。

SELECT * FROM foo JOIN bar ON (foo.foo_id = bar.foo_id);

ただし、参照する主キーと同じ名前を外部キーに付けられない場合があることに注意してください。たとえば、自己参照を持つテーブルでは次のようになります。

CREATE TABLE Employees (
  emp_id INT PRIMARY KEY,
  manager_id INT REFERENCES Employees(emp_id)
);

また、テーブルには、同じ親テーブルへの複数の外部キーがある場合があります。列の名前を使用して関係の性質を説明すると便利です。

CREATE TABLE Bugs (
  ...
  reported_by INT REFERENCES Accounts(account_id),
  assigned_to INT REFERENCES Accounts(account_id),
  ...
);

列名にテーブルの名前を含めるのは好きではありません。また、すべてのテーブルの主キー列の名前として必須の「id」を避けています。

于 2008-10-17T23:17:20.220 に答える
5

ここで提案されたアイデアのほとんどは、私が SQL データベースを使用して開発してきた 20 年以上にわたって支持してきたと言うのは恥ずかしいことです。それらのほとんどは、期待される利点をほとんど、またはまったく提供せず、後から考えると、首の痛みでした.

スキーマに数時間以上費やしたときはいつでも、最も重要なテーブルとその列にすぐに慣れてきました。数ヶ月になると、ほとんど頭の中にすべてが収まります。

このすべての説明は誰のためですか？デザインに数分しか費やさない人は、とにかく深刻なことをするつもりはありません. サンスクリット語で列に名前を付けると、長い間それを使用する予定の人はそれを学びます.

複合主キーを無視すると、「id」のような単純なものが主キーに十分でなく、「_id」が外部キーに十分でない理由がわかりません。

したがって、典型的な結合条件は次のようになりcustomer.id = order.customer_idます。

2 つのテーブル間に複数の関連付けが存在する場合、テーブル名ではなく関連付けを使用する傾向があるため、おそらく「parent_person_id」ではなく「parent_id」と「child_id」などを使用します。

于 2008-10-18T00:19:56.880 に答える
1

主キーの Id サフィックスが付いたテーブル名のみを使用します (CustomerId など)。他のテーブルからそれを参照する外部キーも CustomerId と呼ばれます。アプリケーションで参照すると、Customer.TelephoneNumber、Customer.CustomerId などのオブジェクト プロパティからテーブルが明らかになります。

于 2008-10-17T22:48:01.277 に答える
0

テーブルの外部キーのフロントエンドで "fk_" を使用したのは、主に、自分のショップでプロジェクトの DB を開発するときに、それをまっすぐに保つのに役立ったからです。過去に DB 作業を行ったことがないので、これは役に立ちました。後から考えると、おそらくそれを行う必要はありませんでしたが、一部の列名に 3 文字が追加されていたので、気にしませんでした。

DB アプリケーションを作成する初心者である私は、ベテランの DB 開発者を震撼させるいくつかの決定を下した可能性がありますが、外部キーが実際にそれほど大きな問題であるかどうかはわかりません。繰り返しますが、これはこの問題に関する視点の違いだと思います。私は確かにあなたが書いたことを取り入れて考えます。

良いものを持っている！

于 2008-10-17T22:45:17.740 に答える
-1

私はあなたに同意します-私は多くの企業環境で推奨されているのを見た別のアプローチを取ります：

TableNameFieldNameの形式で列に名前を付けるため、Customerテーブルがあり、UserNameがフィールドの1つである場合、そのフィールドはCustomerUserNameと呼ばれます。つまり、Invoiceという別のテーブルがあり、顧客のユーザー名が外部キーである場合、それをInvoiceCustomerUserNameと呼び、それを参照するときにInvoice.CustomerUserNameと呼びます。これにより、どのテーブルにあるかがすぐにわかります。

また、この命名は、ジョイニングしているときに列が由来するテーブルを追跡するのに役立ちます。

私は、DBMSの外部キーと主キーの実際の名前にFK_とPK_のみを使用しています。

于 2008-10-17T22:32:57.297 に答える