テーブル命名のジレンマ：単数名と複数名の比較[終了]

アカデミアでは、テーブル名は属性を格納するエンティティの単数形である必要があるとしています。

名前の前後に角かっこが必要なT-SQLは嫌いですが、Usersテーブルの名前を単数形に変更しました。

私の直感は、単数形にとどまる方が正しいということですが、私の直感は、括弧がスペースを含む列名などの望ましくないものを示していることでもあります。

私は滞在するべきですか、それとも行くべきですか？

他の人は「標準」まではかなり良い答えを出しましたが、私はこれを追加したいだけです...「ユーザー」（または「ユーザー」）が実際にテーブルに保持されているデータの完全な説明ではない可能性はありますか？テーブル名と具体性に夢中になるべきではありませんが、おそらく「Widget_Users」（「Widget」はアプリケーションまたはウェブサイトの名前です）のようなものがより適切でしょう。

私は同じ質問をしました、そしてここですべての答えを読んだ後、私は間違いなくSINGULARにとどまります、理由：

理由1（概念）。「AppleBag」のようなリンゴを含むバッグを考えることができます。0、1、または100万個のリンゴを含むかどうかは関係ありません。常に同じバッグです。テーブルはそれだけです。コンテナでは、テーブル名はテーブルに含まれるデータの量ではなく、テーブルに含まれるものを記述する必要があります。さらに、複数形の概念は、話し言葉の言語に関するものです（実際に1つ以上あるかどうかを判断するため）。

理由2。（便利）。複数の名前よりも単数の名前の方が簡単です。オブジェクトは不規則な複数形でも複数形でもかまいませんが、常に単数形になります（ニュースのような例外はほとんどありません）。

• お客様
• 注文
• ユーザー
• 状態
• ニュース

理由3。（美的および秩序）。特にマスター/ディテールシナリオでは、これは読みやすく、名前でより適切に整列し、より論理的な順序になります（マスターが最初、ディテールが2番目）。

• 1.ご注文
• 2.OrderDetail

に比べ：

• 1.OrderDetails
• 2.ご注文

理由4（単純さ）。すべてをまとめると、テーブル名、主キー、リレーションシップ、エンティティクラス...は、2つではなく1つ（単数）の名前（単数）、複数のテーブル、単数フィールド、単数-複数のマスター詳細などを認識する方が適切です。 。）

• Customer
• Customer.CustomerID
• CustomerAddress
• public Class Customer {...}
• SELECT FROM Customer WHERE CustomerID = 100

「顧客」を扱っていることがわかったら、データベースとのやり取りのすべてのニーズに同じ単語を使用することができます。

理由5。（グローバリゼーション）。世界はますます小さくなっています。皆さんはさまざまな国籍のチームを抱えている可能性があります。英語を母国語としないプログラマは、「リポジトリ」よりも「リポジトリ」、または「ステータス」の代わりに「ステータス」を考える方が簡単でしょう。名前が単数であることにより、タイプミスによるエラーが減り、「子供か子供か」を考える必要がないため時間を節約でき、生産性が向上します。

理由6。（何故なの？）。書き込み時間を節約し、ディスク領域を節約し、コンピューターのキーボードを長持ちさせることさえできます！

• SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
• SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100

3つの文字、3バイト、3つの追加キーボードヒットを保存しました:)

そして最後に、次のような予約済みの名前をいじって、それらに名前を付けることができます。

• ユーザー> LoginUser、AppUser、SystemUser、CMSUser、...

または、悪名高い角括弧を使用します[ユーザー]

オブジェクトリレーショナルマッピングツールを使用する場合、または将来使用する場合は、Singularをお勧めします。

LLBLGenのような一部のツールでは、テーブル名自体を変更せずに、Users to Userなどの複数名を自動的に修正できます。なぜこれが問題なのですか？それはマップされたとき、Users.NameではなくUser.Nameのように見えるようにしたい、またはコードで混乱しているtblUsers.strNameを命名している私の古いデータベーステーブルのいくつかから悪いことに。

新しい経験則は、オブジェクトに変換された後の外観を判断することです。

私が見つけた1つのテーブルは、私が使用する新しい命名に適合しないものは、UsersInRolesです。ただし、常にいくつかの例外があり、この場合でも、UsersInRoles.Usernameのように見えます。

私は、英語では単数形のたわまない名詞を使用することを好みます。

他の多くの回答が示すように、テーブル名の数に影響を与えると、正字法の問題が発生しますが、通常はテーブルに複数の行が含まれるため、意味的に穴があふれるため、そうすることを選択します。これは、（ほとんどの場合のように）格に基づいて名詞を活用する言語を考えると、より明白になります。

私たちは通常、行を使って何かをしているので、なぜその名前を非難的なケースに入れませんか？読み取る以上に書き込むテーブルがある場合は、名前をdativeに入れてみませんか？それは何かの表です、属格を使ってみませんか？テーブルは、その状態や使用方法に関係なく存在する抽象コンテナーとして定義されているため、これは行いません。正確で絶対的な意味論的理由なしに名詞を活用することは、せせらぎです。

反映されていない名詞の使用は、単純で論理的で、規則的で言語に依存しません。

テーブルに単一の名前を付ける必要があるのはどの規則ですか？いつも複数の名前だと思っていました。

ユーザーが「ユーザー」テーブルに追加されます。

このサイトは同意します：http :
//vyaskn.tripod.com/object_naming.htm#Tables

このサイトは同意しません（ただし、同意しません）：http :
//justinsomnia.org/writings/naming_conventions.html

他の人が述べたように：これらは単なるガイドラインです。あなたとあなたの会社/プロジェクトのために働く慣習を選んで、それに従ってください。単数形と複数形、時には省略形の単語を切り替えることも、そうでない場合もあります。

簡単な例としてこれはどうですか：

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

対

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

後者のSQLは前者よりも奇妙に聞こえます。

単数に投票します。

エンティティリレーションシップダイアグラムでは、エンティティはクラス名が単数形であるのと同様に、単数形の名前で反映されるべきであると私は確信しています。インスタンス化されると、名前はそのインスタンスを反映します。したがって、データベースでは、テーブル（エンティティまたはレコードのコレクション）にしたときのエンティティは複数になります。エンティティ、ユーザーはテーブルユーザーになります。Userという名前をEmployeeまたはあなたのシナリオにより適切なものに改善できると示唆した他の人にも同意します。

レコードのグループから選択しているので、SQLステートメントではこれはより理にかなっており、テーブル名が単数形の場合、うまく読み取れません。

テーブル名やプログラミングエンティティは単数形にします。

理由？マウス⇒マウスとヒツジ⇒ヒツジのように英語には不規則な複数形があること。次に、コレクションが必要な場合は、マウスまたは羊を使用して次に進みます。

これは本当に複数が目立つのを助けます、そして私は物事のコレクションがどのように見えるかを簡単かつプログラム的に決定することができます。

つまり、私のルールは、すべてが単数であり、すべてのコレクションがsを付加した単数であるということです。ORMにも役立ちます。

私見、テーブル名はCustomersのように複数形にする必要があります。

Customersテーブルの行にマップする場合、クラス名はCustomerのように単数である必要があります。

特異な。どちらが最も論理的であるかという議論は購入しません。誰もが自分の好みが最も論理的だと思っています。あなたが何をしてもそれは混乱です、ただ慣習を選んでそれに固執してください。私たちは、非常に不規則な文法とセマンティクス（通常の話し言葉および書き言葉）を持つ言語を、非常に特殊なセマンティクスを持つ非常に規則的な（SQL）文法にマッピングしようとしています。

私の主な主張は、テーブルをセットとしてではなく、関係として考えることです。

したがって、AppUser関係はどのエンティティがであるかを示しAppUsersます。

このAppUserGroup関係から、どのエンティティがAppUserGroups

AppUser_AppUserGroup関係はどのように私に語ったAppUsersとAppUserGroups関係しています。

AppUserGroup_AppUserGroup関係はどのように私に語ったAppUserGroupsし、AppUserGroups（グループのすなわちグループメンバー）に関連しています。

つまり、エンティティとそれらの関係を考えるとき、私は関係を単数で考えますが、コレクションまたはセットのエンティティを考えるとき、コレクションまたはセットは複数です。

私のコードでは、データベーススキーマでは、単数形を使用しています。テキストの説明では、読みやすさを高めるために複数形を使用します。フォントなどを使用して、テーブル/リレーション名を複数形と区別します。

私はそれを散らかったものとして考えるのが好きですが、体系的です-このように、私が表現したい関係には常に体系的に生成された名前があり、それは私にとって非常に重要です。

私は複数形も使用します。前述のユーザーのジレンマでは、角かっこアプローチを採用します。

私たちは、という基本を理解した上で、データベースアーキテクチャとアプリケーションアーキテクチャの両方の間の均一性を提供するために、これを行うユーザーテーブルがの集まりであるユーザーな限り数値ユーザーコードアーティファクトに収集することの集まりであるユーザーオブジェクト。

データチームと開発者が同じ概念言語を話す（常に同じオブジェクト名であるとは限りません）ことで、それらの間でアイデアを伝達しやすくなります。

私は個人的には、セットを表すために複数の名前を使用することを好みます。それは、私の関係の心にとっては単に「音」に優れています。

この時点で、私は会社のデータモデルを定義するために単数形の名前を使用しています。これは、職場のほとんどの人がそれに慣れているからです。時には、個人的な好みを課すのではなく、誰もが簡単に生活できるようにしなければなりません。（それが私がこのスレッドで終わった方法であり、テーブルに名前を付けるための「ベストプラクティス」とは何かを確認するためです）

このスレッドでの議論をすべて読んだ後、私は1つの結論に達しました：

みんなの好きな味が何であれ、私は蜂蜜入りのパンケーキが好きです。しかし、私が他の人のために料理をしているのなら、私は彼らに彼らが好きなものを提供しようと努めます。

特異な。ユーザー行表現オブジェクトの束を含む配列を「ユーザー」と呼びますが、テーブルは「ユーザーテーブル」です。テーブルを、それが含む行のセットにすぎないと考えるのは間違っています、IMO。テーブルはメタデータであり、行のセットはテーブルに階層的にアタッチされています。これはテーブル自体ではありません。

もちろん、私は常にORMを使用しており、複数のテーブル名で記述されたORMコードが愚かに見えるのを助けます。

私は実際には、複数のテーブル名を使用することが一般的な慣習であるといつも思っていました。ここまでは常に複数を使用してきました。

単数形のテーブル名の引数は理解できますが、複数形の方が理にかなっています。テーブル名は通常、テーブルの内容を示しています。正規化されたデータベースでは、各テーブルに特定のデータセットが含まれています。各行はエンティティであり、テーブルには多くのエンティティが含まれています。したがって、テーブル名の複数形。

車のテーブルには名前の車があり、各行は車です。フィールドと一緒にテーブルを指定するのtable.fieldがベストプラクティスであり、単一のテーブル名を使用する方が読みやすいことを認めます。ただし、次の2つの例では、前者の方が意味があります。

SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'

正直なところ、私はこの問題について自分の立場を考え直し、私が開発している組織で使用されている実際の規約に依存します。ただし、個人的な慣習として、複数のテーブル名を使用することにします。私にはもっと理にかなっています。

英語の一部の名詞は数えられない（水、スープ、現金）か、数えられるようにすると意味が変わる（チキンvsチキン、肉vs鳥）ので、複数のテーブル名は好きではありません。また、テーブル名または列名に略語を使用することは、既に急な学習曲線に勾配を追加するため、嫌いです。

皮肉にも、USER（Transac-SQL）が原因でUser例外を作成して呼び出す可能性があります。必要がない場合は、テーブルの前後に角かっこを使用したくないからです。Users

また、すべてのID列の名前をId、 ChickenIdまたはにしChickensIdたいと思います（これについて複数の人が何をするのですか？）。

これはすべて、データベースシステムを適切に尊重していないためです。私は、Javaの癖や怠惰などのOO命名規則からのワントリックポニーの知識を再利用しています。複雑なSQLのためのより良いIDEサポートがあればいいのに。

私たちは同様の標準を実行します。スクリプトを作成するとき、名前の周りに[]を要求し、適切な場合はスキーマ修飾子を使用します。

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

これにより、過去に私たちの魂が救われました-一部のデータベースシステムは、SQL 6.0からSQL 2005まで10年以上稼働しています-意図した寿命をはるかに超えています。

テーブル：複数

usersテーブルには複数のユーザーがリストされています。

モデル：単数

usersテーブルから単一のユーザーを選択できます。

コントローラ：複数

http://myapp.com/usersは複数のユーザーをリストします。

とにかくそれは私の考えです。

CASE構文を使用してERダイアグラムを読みやすくするため、私は単一のテーブル名のファンですが、これらの応答を読むことで、あまりうまく捉えられていないような感じがしますか？個人的には大好きです。単数形のテーブル名を使用し、関係にアクション動詞を追加し、すべての関係に対して適切な文を作成する場合のモデルの読みやすさの例を含む概要があります。20テーブルデータベースの場合は少しやり過ぎですが、数百のテーブルと複雑な設計を備えたDBがある場合、開発者は読みやすい図なしでそれを理解するにはどうすればよいでしょうか。

http://www.aisintl.com/case/method.html

テーブルとビューにプレフィックスを付けることに関しては、私はその実践を絶対に嫌います。おそらく悪い情報を与える前に、人に情報をまったく与えないでください。オブジェクトのデータベースを参照している人は誰でもビューからテーブルを簡単に見分けることができますが、tblUsersという名前のテーブルがある場合、何らかの理由で将来的に2つのテーブルに再構成することにし、ビューを統合して古いコードを壊さないようにしますこれで、tblUsersという名前のビューができました。この時点で、2つの魅力的なオプションが残っています。tblプレフィックスを付けた名前のビューを残すと、一部の開発者を混乱させる可能性があります。または、新しい構造またはviewUsersという名前を参照するように、中間層またはアプリケーションの別のレイヤーを強制的に書き換えます。これは、ビューIMHOの価値の大部分を無効にします。

システムtables/viewsサーバ自体の（SYSCAT.TABLES、dbo.sysindexes、ALL_TABLES、information_schema.columns、など）はほとんど常に複数です。一貫性のために、私は彼らの先導に従うと思います。

MS SQL Server'sシステムテーブルを見ると、Microsoftによって割り当てられた名前がにありpluralます。

Oracleのシステムテーブルの名前はにありsingularます。それらのいくつかは複数ですが。ユーザー定義の表名には複数形をお薦めします。それは彼らがあることを推奨し、別のものに従うことはあまり意味がありません。これらの2つのソフトウェアジャイアントのアーキテクトが異なる規則を使用してテーブルに名前を付けたことは、あまり意味がありません...結局のところ、これらの連中は何ですか...博士

私は学界で覚えています、推薦は単数でした。

たとえば、次のように言うと、

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

多分b / cそれぞれIDが特定の単一の行から選択されます...？

これは少し冗長かもしれませんが、注意することをお勧めします。テーブルの名前を変更することは必ずしも悪いことではありませんが、標準化はそれだけです。標準-このデータベースはすでに「標準化」されている可能性がありますが、ひどく:)-このデータベースがすでに存在し、おそらく2つ以上のテーブルで構成されていることを考えると、一貫性をより良い目標にすることをお勧めします。

データベース全体を標準化できない場合、または少なくともその目的に向かって作業することを計画している場合を除いて、テーブル名は氷山の一角にすぎず、手元のタスクに集中して、名前の悪いオブジェクトの苦痛に耐えているのではないかと思いますあなたの最善の利益-

実用的な一貫性が最高の基準になることもあります... :)

my2cents ---

可能な選択肢：

• テーブルの名前をSystemUserに変更します。
• ブラケットを使用する
• 複数のテーブル名を保持します。

ブラケットを使用したIMOは、技術的に最も安全な方法ですが、少し面倒です。IMOは6の1つ、他の6ダースであり、ソリューションは実際には個人/チームの好みに要約されます。

私の見解は、コンテナーの定義方法に応じてセマンティクスにあります。たとえば、「りんごの袋」または単に「りんご」または「りんごの袋」または「りんご」。

例：「大学」の表には0以上の大学を含めることができます「大学」の表には0以上の大学を含めることができます

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

私の結論は、どちらでも問題ないということですが、テーブルを参照するときに、自分（またはそれと対話する人々）がどのようにアプローチするかを定義する必要があります。「axテーブル」または「xsのテーブル」

他の人がここで述べたように、慣習は使いやすさと読みやすさを増すためのツールであるべきです。開発者を拷問するための束縛やクラブとしてではありません。

とはいえ、私の個人的な好みは、テーブルと列の両方に単一の名前を使用することです。これはおそらく私のプログラミングの背景によるものです。クラス名は、何らかのコレクションでない限り、通常は単数形です。私の考えでは、問題のテーブルの個々のレコードを格納したり読み取ったりしているので、単数形は理にかなっています。

この方法により、オブジェクト間の多対多の関係を格納するテーブル名に複数のテーブル名を予約することもできます。

テーブルと列の名前にも予約語を使用しないようにしています。ここで問題となっているケースでは、ユーザーの予約語を使用するテーブルをカプセル化する必要を回避するために、ユーザーの単一の規則に対抗する方が理にかなっています。

プレフィックスを限られた方法で使用するのが好きです（テーブル名にはtbl、プロシージャ名にはsp_など）。また、名前を入力するときは常に_ではなく+を押すため、アンダースコアよりもCamelBackの名前を優先します。他の多くは同意しない。

命名規則のガイドラインに役立つ別のリンクを次に示します。http：//www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

規約で最も重要な要素は、問題のデータベースを操作する人々にとって意味があるということです。命名規則に関しては、「すべてを統括する1つのリング」はありません。

単数形を使うことは、私たちが大学で教えたものだと思います。しかし同時に、オブジェクト指向プログラミングとは異なり、テーブルはレコードのインスタンスではないと主張することもできます。

英語の不規則性が複数あるため、現時点では単数形を支持していると思います。ドイツ語では、一貫した複数形がないためにさらに悪化します。単語の前に特定の冠詞（der / die / das）がなければ、単語が複数形であるかどうかを判別できない場合があります。とにかく中国語には複数形はありません。

私はかつてユーザーテーブルに "Dude"を使用しました-同じ短い文字数で、キーワードとの競合はありませんが、それでも一般的な人間への参照です。コードが表示されるかもしれない頭が気にならないのであれば、そのままにしておいたでしょう。

単数形を使用してきたのは、それが教えられたからです。ただし、最近新しいスキーマを作成する際に、久しぶりにこの規則を維持することを積極的に決定しました。すべてのテーブル名の末尾に 's'を追加することは、すべてのテーブル名の前に 'tbl_'を追加するのと同じくらい役に立たないようです。

私はいつもそれは馬鹿げた慣習だと思っていました。複数のテーブル名を使用しています。

（私はそのポリシーの背後にある合理的な理由は、ORMコードジェネレーターがオブジェクトとコレクションクラスを生成するのを容易にすることです。逆の場合よりも単数の名前から複数の名前を生成する方が簡単だからです）

単数形でも複数形でも、スペルが同じテーブル名には名詞のみを使用します。

ムース魚鹿航空機パンツショートパンツメガネはさみ種子孫

私はこれが以前のどの回答でも明確に表現されているのを見ませんでした。多くのプログラマーは、テーブルを扱う際に正式な定義を考えていません。「レコード」または「行」に関して直感的にコミュニケーションをとることがよくあります。ただし、非正規化された関係の一部の例外を除いて、テーブルは通常、非キー属性とキーの間の関係が集合理論関数を構成するように設計されています。

関数は、2つのセット間のクロス積のサブセットとして定義できます。この場合、キーのセットの各要素は、マッピングで最大1回発生します。したがって、その観点から生じる用語は単数である傾向があります。関数（代数やラムダ計算など）を含む他の数学的および計算理論全体で同じ単数（または少なくとも非複数）の規則が見られます。