例:
CREATE TABLE ErrorNumber
(
ErrorNumber int,
ErrorText varchar(255),
)
これにより、次のようなクエリが発生する可能性があります。
SELECT ErrorNumber FROM ErrorNumber WHERE ErrorNumber=10
例:
CREATE TABLE ErrorNumber
(
ErrorNumber int,
ErrorText varchar(255),
)
これにより、次のようなクエリが発生する可能性があります。
SELECT ErrorNumber FROM ErrorNumber WHERE ErrorNumber=10
テーブルの列としての ErrorNumber が主キーであると仮定していますか? この場合、テーブル列に ErrorNumberID という名前を付けることができます。
コーディング方法が悪いのかどうかはわかりませんが、読みやすさのために何かをしているとは思えません。あなたが提供した例は、クエリがどれほど混乱するかを示すのに最適です。
私が確信していないもう1つのことは、これ(列名がテーブル名と同じである)がエラーを引き起こすかどうかです。メーカーによって違うと思います。
CREATE TABLE Errors (
Number int,
Description varchar(255)
)
次の理由から、上記の命名スキームの方が優れていると思います。
デフォルトのままにして、主キー ID に名前を付けることができます。
テーブルと同じ名前を共有する列を持つことは良い考えではないと思います。動いていても紛らわしい。テーブルの名前を Error に変更するか、列の名前を ErrorNum または単に Num に変更してみてください
私は DWC に同意します。エラー テーブルの種類など、もう少し説明的な名前をテーブルに付けるには、さらに一歩進んでください。コードで使用するエラーを格納するために使用される場合と、エラーをログに記録するテーブルである場合は別です。それを何のために使用しているのかわからないので、それが使用されているコンテキストに意味のある名前を付けるのは本当にあなた次第です。「エラー」という名前のテーブルが表示されたとき、それがログ テーブルなのか、エラー コードの検索に使用されるルックアップ テーブルなのかわかりません。後者の場合は、おそらく ErrorCodes のような名前が適しています。
CREATE TABLE ErrorCodes
(
Id int,
Number int,
Description varchar(255)
)
はい、そうです。単純なデータ モデルの単純なテーブルの大部分は、複数形の名詞にする必要があります。あなたの例では、テーブルは「エラー」と呼ばれ、「id」と「説明」の2つの列があります。
dwcの簡潔な名前の場合は+1。
「列名は値のドメインを示す必要がある」という問題は、コンテキストを見落とすことです。列名は、テーブルのコンテキストにのみ存在します。あいまいになることはありません。そのドメインは、その名前とは無関係に制御されます。
Errors.Description
とParts.Description
を区別できない人、または名前が付けられた、または同じ聖なる井戸から描かれたすべての列を想定する人は存在しますか Problems.Description
?Description
Name
とはいえ、主キー列にNumberやIDなどの一般的な用語を使用することはありません。これは、非常に異なる理由です。列には、外部キーとして表示される新しい名前が必要です。
たとえば、エラー番号をActions
テーブルに記録する必要があるとします。 Actions.Number
エラー番号を参照できない可能性があるため、のようなものを発明する必要がありますActions.ErrorNumber
。それが他のどこにでもあるのであればErrorNumber
、それが鍵となるのと同じ名前を持っているかもしれません!
それは形式の問題です。個人的には、ほとんどのテーブル名を複数形にしています。この特定のケースでは、テーブルは ErrorNumbers になり、テーブル フィールドは ErrorNumber になります (実際には ErrorNumberID を使用します)。
繰り返しますが、それはあなたまたはあなたの会社のコーディング基準次第です。フォームが悪い場合は、極めて軽微な違反です。どちらかといえば、変数名に ID が欠落していることが違反です。
テーブルが複数の行で構成されることが予想される場合、私の好みは総称を名前として使用することです。これは、単数形を取って「s」を追加することと同じではないことに注意してください。たとえば、「Employees」と「EmployeesSalaries」よりも「Personnel」と「Payroll」をそれぞれ好むと思います。そして、「エンティティ」などの名前を取り出して撃つ必要があります:)
これに照らして、設計の列を考慮して、問題のテーブルに「エラー」という名前を付けます。さて、多くのコーダーがテーブル名に単数形の用語を好むことは知っていますが、それは「貧弱なコーディング慣行」ではなく、単に別のスタイルです。
DBMS を使用するアプリケーションで使用される pi の共有近似値を含むテーブル「定数」など、単一行テーブルが必要になる場合があります...しかし、私が考えている「定数」テーブルには、それぞれ異なる定数に対して複数の列があります。そのため、総称として名前が付けられます。
おそらく、アプリケーションが 1 つの定数しか使用しなかった場合、'Pi' という名前のテーブルになる可能性があります。私が行った別のスタイルの選択は、テーブル名に UpperCamelCase を使用し、列名に lower_case_separated_by_underscores を使用することです。したがって、テーブルと列を(ほぼ)区別することができます。
SELECT pi FROM Pi;
[また、SO にあるようなコード パーサーを使用すると、作業も簡単になります!]
実際、私はほとんど排他的にテーブル相関名を使用する傾向があるため、次のように書く可能性が高くなります。
SELECT P1.pi
FROM Pi AS P1;
また、「種」、「鹿」、「羊」、「魚」など、いくつかの集合用語は単数用語と同じように綴られていることも考慮してください。おそらく、動物界に関係のない他の多くの用語もありますが、私は今、精神的なブロックを抱えています:)
したがって、私が好むデータ要素の命名規則を使用しても、同じ名前の列を含む SQL テーブルを想定することはできますが、実際にはめったに発生しません。
それは貧しいですか?わずかかもしれませんが、大したことではありません。
それは大したことではないことに同意します。
アプリケーションには、id と「name」フィールドのみを持つ多数のテーブルがあります。これらはドロップダウン リストに使用されます。
そこで、次のように設定しました。
リスト名: State
テーブル名: State
ID は: StateID
実際の状態の値の列: StateName
それは私たちのために働きます。
あなたの特定のケースでは、上記のように行い、テーブルにエラーという名前を付けるだけです。
それによって混乱するデータベース ベンダーがある場合は、別のデータベース ベンダーを使用してください。どのデータベースでも問題なく簡単に解析できます。
読みやすさの理由から、おそらく良い習慣ではないことに同意します。