テーブル命名のジレンマ：単数形と複数形の名前
学界は、テーブル名はそれらが属性を格納するエンティティの単数形であるべきだと考えています。
名前の前後に角括弧を必要とするT-SQLは嫌いですが、Usersテーブルを単数形に名前を変更しました。
私の直感は、単数形にとどまることがより正しいということですが、私の直感はまた、括弧がそれらの中にスペースを含む列名のような望ましくないことを示すということです。
私は滞在すべきですか、それとも私は行かなければなりませんか？
他の人たちは「標準」に関してはかなり良い答えを出していますが、私はこれを追加したいと思いました。 ？テーブル名と具体性に夢中になるべきではありませんが、おそらく "Widget_Users"（ "Widget"はアプリケーションまたはWebサイトの名前）のようなものが適しています。
私は同じ質問をしました、そして、ここですべての答えを読んだ後に、私は間違いなくSINGULARにとどまります、理由：
理由1 （コンセプト）。あなたは "AppleBag"のようなりんごを含んでいるバッグを考えることができます、それが0、100または百万個のりんごを含んでいるかどうかは関係ありません、それは常に同じバッグです。テーブルは、コンテナ、テーブル名は、それが含むデータの量ではなく、それが含むものを記述しなければならないということです。さらに、複数形の概念は、話し言葉に関する概念です（実際には1つ以上あるかどうかを判断するため）。
理由2 。 （利便性）複数の名前よりも、単数の名前の方が簡単です。オブジェクトは不規則な複数形を持っていても、複数形でなくてもかまいませんが、常に単一のものを持つことになります（Newsのような少数の例外はあります）。
- 顧客
- 注文
- ユーザー
- 状態
- ニュース
理由3 。 （美的と秩序）。特にマスター/ディテールのシナリオでは、これは読みやすく、名前で整列しやすく、論理的な順序が多くなります（マスターが最初、詳細が2番目）。
- 1.オーダー
- 2.注文詳細
に比べ：
- 1.注文詳細
- ご注文
理由4 （単純さ）まとめると、テーブル名、主キー、リレーションシップ、エンティティクラス...は、2つ（単数クラス、複数テーブル、単数フィールド、単数 - 複数マスター詳細）ではなく、1つの名前（単数）のみを認識してください。 。）
CustomerCustomer.CustomerIDCustomerAddresspublic Class Customer {...}SELECT FROM Customer WHERE CustomerID = 100
あなたがあなたが "顧客"を扱っていることを知ったら、あなたはあなたがあなたのデータベースインタラクションの必要性の全てのためにあなたが同じWordを使うことを確信することができます。
理由5 。 （グローバリゼーション）世界は狭くなっています、あなたは異なる国籍のチームを持っているかもしれません、誰もが母国語として英語を持っているというわけではありません。英語を母国語としないプログラマーにとっては、「リポジトリ」や「ステータス」ではなく「ステータス」を考えるほうが簡単です。単数形の名前を使用すると、タイプミスによるエラーを減らすことができます。「子供ですか、それとも子供ですか？」と考える必要がないため、時間を節約でき、生産性が向上します。
理由6 。 （何故なの？）。書き込み時間を節約し、ディスク容量を節約し、コンピュータのキーボードを長持ちさせることもできます。
SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100
あなたは3文字、3バイト、3つの追加キーボードヒットを保存しました:)
そして最後に、次のような予約済みの名前でそれらを混乱させている名前を付けることができます。
- ユーザー> LoginUser、AppUser、SystemUser、CMSUser、...
または悪名高い角括弧を使用する[ユーザー]
Object Relational Mappingツールを使用する場合、または将来的には Singular をお勧めします。
LLBLGenのようないくつかのツールは、テーブル名自体を変更することなく、ユーザーからユーザーへのような複数の名前を自動的に修正することができます。これはどうしてですか。それがマッピングされるとき、あなたはそれがUsers.Nameの代わりにUser.Nameのように見えることを望むか、またはコードを混乱させるだけのtblUsers.strNameを命名する私の古いデータベーステーブルのいくつかからさらに悪いことを望みます。
私の新しい経験則は、オブジェクトに変換された後の外観を判断することです。
私が使用している新しい命名法に合わないという私が見つけた1つのテーブルは、UsersInRolesです。しかし、これらのいくつかの例外は常にあり、この場合でもUsersInRoles.Usernameのように正常に見えます。
私は 無関係な 名詞を使うことを好む。これは英語では単数形であることが起こる。
テーブル名の番号を変更すると（他の多くの回答が示すように）表記上の問題が発生しますが、通常はテーブルに複数の行が含まれるため、これを選択すると意味的に穴があふれます。大部分の場合と同様に、大文字小文字に基づいて名詞を活用する言語を検討すると、これはより明白になります。
我々は通常行を使って何かをしているので、なぜ対格的な場合に名前を入れないのですか？我々が我々が読む以上に書くテーブルを持っているならば、なぜ名前を仮説に入れないのですか？それは何かの表です of テーブルはその状態や使用法に関係なく存在する抽象コンテナとして定義されているため、これは行いません。厳密で絶対的な意味論的な理由なしに名詞を活用することは不可解です。
無関係の名詞を使うのは簡単で、論理的で、規則的で、そして言語に依存しません。
テーブルが単数の名前を持つことをどのような規則が必要としますか？私はいつもそれが複数の名前だと思った。
ユーザーが「ユーザー」テーブルに追加されます。
このサイトは同意します：
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"
vs.
SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"
後者のSQLは前者よりも奇妙に聞こえます。
singular に投票します。
エンティティ関係図では、クラス名が単数形であるのと同様に、エンティティは単数形で反映されるべきだと私は確信しています。インスタンス化されると、名前はそのインスタンスを反映します。そのため、データベースでは、エンティティをテーブル（エンティティまたはレコードの集まり）にしたときのエンティティは複数形になります。エンティティ、ユーザーはテーブルUsersになります。私は、ユーザーという名前を従業員に、あるいはあなたのシナリオにより適したものにすることができるかもしれないと提案した他の人々に同意するでしょう。
これはSQL文では意味があります。レコードのグループから選択しているためです。また、テーブル名が単数形の場合は読みにくいです。
私は 単数形の テーブル名とあらゆるプログラミング実体のために固執します。
理由？ mouse⇒mice および sheep⇒sheep のように英語に不規則な複数形があるという事実。次に、 collection が必要な場合は、 mouses または sheeps を使用して次に進みます。
それは本当に複数が際立っているのを助けます、そして、私は物事の集まりがどのように見えるかということを容易にそしてプログラム的に決定することができます。
だから、私のルールは、すべてが特異であること、すべてのものが s が付いた特異であることです。 ORMにも役立ちます。
特異な。私は、最も論理的であるという議論を買うことはしません - すべての人が、自分の好みが最も論理的であると考えています。あなたが何をしてもそれはめちゃくちゃです、単に慣例を選んでそれに固執してください。我々は、非常に不規則な文法と意味を持つ言語（普通の話し言葉と書かれた言語）を非常に特定の意味を持つ非常に規則的な（SQL）文法にマッピングしようとしています。
私の主な主張は、私はテーブルを集合としてではなく、関係として考えることです。
したがって、AppUser関係は、どのエンティティがAppUsersであるかを示します。
AppUserGroup関係はどの実体がAppUserGroupsであるかを教えてくれます
AppUser_AppUserGroupの関係は、AppUsersとAppUserGroupsがどのように関連しているかを教えてくれます。
AppUserGroup_AppUserGroupの関係は、AppUserGroupsとAppUserGroupsがどのように関連しているか（つまり、groupsがgroupsのメンバー）を教えてくれます。
言い換えれば、私は実体とそれらがどのように関連しているかについて考えるとき、私は単数で関係を考えるが、もちろん私がコレクションまたは集合の実体を考えるとき、集合または集合は複数である。
私のコードでは、そしてデータベーススキーマでは、私は単数形を使用します。テキストによる説明では、読みやすさを増すために複数形を使用することになります。それからフォントなどを使用して、表や関係の名前を複数形から区別します。
私はそれを厄介ではあるが体系的であると考えるのが好きです - そしてこのように私が表現したい関係のために体系的に生成された名前が常にあり、それは私にとって非常に重要です。
私見、テーブル名は 複数 like Customers であるべきです。
クラス名が Customers テーブルの行にマップされる場合、クラス名は Customer のように単数形にする必要があります。
また、私は複数を使い、前述の Users のジレンマでは、角括弧で囲むアプローチを取ります。
Users テーブルは User と同数の Users 値の集まりであるという基本的な理解のもと、データベースアーキテクチャとアプリケーションアーキテクチャの両方に統一性を持たせるためにこれを行います。コード成果物内の/ collectionは、 User オブジェクトのコレクションです。
私たちのデータチームと私たちの開発者が同じ概念的な言語（いつも同じオブジェクト名ではないが）を話すようにすることはそれらの間でアイデアを伝えることをより簡単にします。
私は個人的に集合を表現するために複数の名前を使うことを好みます、それは私のリレーショナルマインドにちょうど「聞こえます」。
現時点で、私は自分の会社のデータモデルを定義するために単数形の名前を使用しています。これは、職場のほとんどの人がそれに満足していると感じるためです。あなたの個人的な好みを課すのではなく、時にはあなたはただ誰もが人生を楽にしなければならないだけです。 （これが、私がこのスレッドにたどり着いた理由です。テーブルの命名のための「ベストプラクティス」が何であるべきかの確認を得るため）
このスレッドのすべての議論を読んだ後、私は1つの結論に達しました。
みんなの好きな風味が何であれ、私は蜂蜜と私のパンケーキが好きです。しかし、私が他の人のために料理をしているのなら、私は彼らに彼らが好きなものを提供しようとします。
特異な。一連のユーザー行表現オブジェクトを含む配列を 'users'と呼びますが、テーブルは 'the user table'です。テーブルをその中に含まれる行のセットに他ならないと考えるのは間違っています、IMO。テーブルはメタデータであり、行のセットはテーブルに階層的に関連付けられています。テーブル自体ではありません。
私はもちろんORMをいつも使っています、そしてそれは複数のテーブル名で書かれたORMコードがバカに見えるのを助けます。
私は複数のテーブル名が好きではありません。なぜなら英語のいくつかの名詞は数えられないので（水、スープ、現金）、または数えられると意味が変わります（チキン対チキン、肉対鳥）。また、テーブル名やカラム名に略語を使用するのは嫌いです。なぜなら、そうすることで、すでに急勾配の学習曲線に余分な勾配が加わるからです。
皮肉なことに、 USER（Transac-SQL） のため、Userを例外にしてUsersと呼ぶこともあります。
私はまた、すべてのID列をIdやChickenIdではなくChickensIdと名付けるのが好きです（複数の人がこれについて何をしているのでしょうか）。
これは、データベースシステムを尊重しているわけではないためです。私は、 Javaの のような命名規則からOO命名規則からワントリックポニーの知識を再適用しているだけです。複雑なSQLに対するIDEサポートが改善されたことを願います。
私は実際には複数のテーブル名を使用するのが一般的な規約であると常に思っていました。この時点まで、私はいつも複数形を使っていました。
単数のテーブル名に対する議論は理解できますが、私には 複数 がもっと理にかなっています。テーブル名は通常、テーブルの内容を表します。正規化データベースでは、各テーブルに特定のデータセットが含まれています。各行はエンティティであり、テーブルには多数のエンティティが含まれています。したがって、テーブル名の複数形です。
自動車のテーブルは cars という名前を持ち、各行は自動車です。 table.fieldの方法でフィールドと一緒にテーブルを指定するのがベストプラクティスであり、単数のテーブル名を持つ方が読みやすいことを認めます。ただし、次の2つの例では、前者の方が理にかなっています。
SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'
正直なところ、私はこの問題に関する私の立場を再考することになります。そして、私は自分が開発している組織で使用されている実際の規則に頼ります。しかし、私は私の個人的な慣習のために、私は複数のテーブル名を使い続けるつもりだと思います。私にはそれはもっと理にかなっています。
私たちが名前[]を要求するスクリプトを書くとき、そして適切なスキーマ修飾子を使うとき - 私たちは同様の標準を実行します - 主にそれは将来の名前に対するあなたの賭けをSQL構文によってつかみます。
SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'
これは過去の私達の魂を救ってくれました - 私達のデータベースシステムの中には意図された寿命を過ぎて10年以上SQL 6.0からSQL 2005まで走っているものがあります。
CASE構文を使用したER図は読みやすくなっているので、私は単数形のテーブル名が大好きですが、これらの回答を読むことで、あまりうまく理解できないと感じていますか？私は個人的にそれが大好きです。単数形のテーブル名を使用したり、関係にアクション動詞を追加したり、すべての関係に適切な文を作成したりするときに、モデルがどの程度読みやすくなるかの例を示した概要があります。 20テーブルのデータベースを作成するにはやややり過ぎですが、何百ものテーブルと複雑な設計を持つDBがある場合、開発者は読みやすい図がないとどのように理解できるでしょうか。
http://www.aisintl.com/case/method.html
テーブルやビューの接頭辞については、私はそのやり方が絶対に嫌いです。彼らにおそらく悪い情報を与える前に、人に全く情報を与えないでください。 dbをオブジェクトとして参照する人はだれでもビューからテーブルを簡単に見分けることができますが、tblUsersという名前のテーブルがあるために、将来、2つのテーブルに再構成することにしました。私は今、tblUsersという名前のビューを持っています。現時点では、2つの魅力的なオプションがあります。ビューをtblプレフィックスで名前を付けたままにすると、開発者を混乱させるか、別の層（中間層またはアプリケーション）を新しい構造またはviewUsersを参照するように書き直す必要があります。それは私見の見解の価値の大部分を否定する。
テーブル：複数
複数のユーザーがusersテーブルに一覧表示されます。
モデル：特異
単一のユーザーをusersテーブルから選択できます。
コントローラ：複数
http://myapp.com/users は複数のユーザーをリストします。
とにかくそれが私の考えです。
サーバー自体のシステムtables/views（SYSCAT.TABLES、dbo.sysindexes、ALL_TABLES、information_schema.columnsなど）は、ほとんど常に複数形です。一貫性のために私は彼らのリードに従うと思います。
これは少し冗長かもしれませんが、慎重になることをお勧めします。必ずしもテーブルの名前を変更するのが悪いことではありませんが、標準化はそれだけです。標準 - このデータベースはすでに「標準化」されているかもしれませんが、ひどいことに:) - このデータベースがすでに存在し、おそらくそれが2つ以上のテーブルからなることを考えると、一貫性をより良い目標にすることをお勧めします。
データベース全体を標準化できないか、少なくともその目的に向かって作業することを計画しているのでなければ、テーブル名は氷山の一角にすぎず、名前の悪いオブジェクトの苦痛を乗り越えて手元のタスクに集中するのではないでしょうか。あなたの最善の関心 -
実用的な一貫性が時々最善の基準です... :)
my2cents ---
私の考えはあなたがあなたのコンテナをどのように定義するかによって意味論にあります。たとえば、 "りんごの袋"、または単に "りんご"、または "Apple bag"や "Apple"などです。
例： "college"テーブルは0個以上の大学を含むことができます "colleges"のテーブルは0個以上の大学を含むことができます
a "student" table can contain 0 or more students
a table of "students" can contain 0 or more students.
私の結論は、どちらでも問題ないということですが、テーブルを参照するときにあなた（またはそれと対話する人々）がどのようにアプローチするかを定義する必要があります。 「xテーブル」または「xsのテーブル」
考えられる代替案
- テーブルの名前をSystemUserに変更する
- 角かっこを使う
- 複数のテーブル名を保存してください。
ブラケットを使用したIMOは技術的に最も安全なアプローチですが、少し面倒です。 IMOは6分の1、2分の1の6、そしてあなたの解決策は実際には個人/チームの好みにかなっています。
MS SQL Server'sシステムテーブルを見ると、Microsoftによって割り当てられているそれらの名前はpluralにあります。
Oracleのシステムテーブルの名前はsingularです。それらのいくつかは複数ですが。ユーザー定義の表名には複数形を使用することをお薦めします。それは彼らが一つのことを推薦して別のものに従うということはあまり意味がありません。これら2つのソフトウェア大手のアーキテクトが異なる命名法を使って自分たちのテーブルに名前を付けたということも、あまり意味がありません。
私は学界で覚えていますが、その推奨は単数形でした。
たとえば、
select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'
たぶんb/cそれぞれのIDは特定の単一行から選択されます…？
私はいつもそれが私が教えられたものであるという理由だけで単数形を使いました。しかし、最近新しいスキーマを作成している間、久しぶりに、私は積極的にこの規則を維持することにしました。すべてのテーブル名の最後に 's'を追加するのは、すべてのテーブル名の前に 'tbl_'を追加するのと同じくらい役に立ちません。
単数形を使用することは、大学で教えられたものだと思います。しかし、同時にcouldは、オブジェクト指向プログラミングとは異なり、テーブルはそのレコードのインスタンスではないと主張します。
英語の複数の不規則性のため、私は現時点で単数形を支持していると思います。ドイツ語では、複数形が一貫していないためさらに悪化しています。Wordが複数形かどうかは、その前に記事（der/die/das）を指定しないとわかりません。とにかく中国語には複数形はありません。
他の人がここで述べたように、慣習は使いやすさと読みやすさを増すための道具であるべきです。開発者を拷問するための束縛やクラブとしてではありません。
とは言っても、私の個人的な好みは、表と列の両方に単一の名前を使用することです。これはおそらく私のプログラミングの背景から来ています。ある種のコレクションでない限り、クラス名は通常単数形です。私の頭の中では、問題のテーブルに個々のレコードを格納したり読んだりしているので、単数形は私にとって意味があります。
これにより、オブジェクト間の多対多の関係を格納するテーブルに複数のテーブル名を予約することもできます。
私は自分のテーブル名とカラム名の予約語も避けるようにしています。ここで問題となっているケースでは、ユーザーのための予約語を使用するテーブルをカプセル化する必要性を避けるためにユーザーのための特異な慣習に反することがより理にかなっています。
私は限られた方法（テーブル名にはtbl、プロシージャ名にはsp_など）でプレフィックスを使うのが好きですが、これは混乱を招くと信じています。キャメルバックの名前にアンダースコアを付けることも好みます。名前を入力するときは、_ではなく+を押すことになるからです。他の多くの人は同意しません。
これは、命名規則のガイドラインに関するもう1つの良いリンクです。 http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/
あなたの規約で最も重要な要素は、それが問題のデータベースと対話する人々にとって意味があるということです。命名規則に関しては、「すべてを統一するための指輪」はありません。
私はいつもそれがばかげた大会だと思った。複数のテーブル名を使用しています。
（この方針の背後にある合理的な理由は、ORMコードジェネレータがオブジェクトクラスとコレクションクラスを生成するのが簡単になることです。逆の場合よりも単数の名前から複数の名前を生成する方が簡単だからです）
私はかつてUserテーブルに "Dude"を使用しました - 同じ短い数の文字、キーワードとの衝突はありません、それでも一般的な人間への参照です。コードを見ることができる頭の痛い部分について私が心配していなかったら、私はそのようにそれを保ったでしょう。
単数形でも複数形でも、同じスペルのテーブル名には名詞のみを使用します。
ムース魚鹿航空機あなたがパンツショーツ眼鏡はさみ種の子孫
ガイドラインはまさにそのとおりです。それはあなたがそれらを無視することができるという選択肢を持っている理由である「石に置かれている」わけではありません。
複数のテーブル名を持つほうが論理的に直感的です。テーブルは結局のところエンティティのコレクションです。言及された他の選択肢に加えて、私は一般的にテーブル名の接頭辞を見ます...
- tblUser
- tblこれ
- tblThat
- tblTheその他
私はこれが行くべき道であることを示唆していない、私はまた私が嫌がるテーブル名の中でスペースがLOTを使っているのを見る。私は馬鹿げた文字のようなフィールド名に出くわすことさえありますか？このフィールドが質問に答えているかのように。
単数形 の名前を使用する理由を説明します。
たとえば、ユーザーからすべてのフィールドを取得する必要があります。
-- Select every fields from 'user' table
SELECT * FROM user
21歳のユーザーの名前が必要です。
-- Select every fields from 'user' table which have 21 years old
SELECT * FROM user WHERE age = '21'
もちろん、複数の方法を同じ方法で使用できますが、私の頭脳が読むには、それが正しい方法だと思います。
テーブルのSQL定義は、実際には、コレクションではなく、テーブルの1つの潜在的な行の定義です。したがって、その定義で使用される名前は、コレクションの名前ではなく、行のタイプを指定する必要があります。英語の文をよく読むので複数形を好む人は、もっと論理的に考え始め、実際にテーブルを使用するのに関わるすべてのロジックとプログラミングコードを調べる必要があります。これらのコメントに記載されている、単数のテーブル名を使用する理由はいくつかあります。これらには複数のテーブル名を使わないという非常に良い理由があります。 「よく読む」といっても、特に理由があるとは限りません。アイデアの読み方が異なる場合があります。
あなたが行けばそこに悩みがあるでしょう、しかしあなたがとどまるならそれは二倍になるでしょう。
私はむしろ予約語であるかもしれない何かにちなんで私のテーブルに名前を付けることよりもむしろいくつかの仮定された非複数形の命名規則に反対したいです。
私はこれが前の答えのどれにもはっきりとはっきりしているのを見ませんでした。多くのプログラマーは、テーブルを扱う際に正式な定義を念頭に置いていません。 「レコード」や「行」という言葉で直感的にコミュニケーションをとることがよくあります。ただし、非正規化された関係を除いて、テーブルは通常、非キー属性とキーの間の関係が集合論的関数を構成するように設計されています。
関数は、2つのセット間の外積のサブセットとして定義できます。この場合、キーセットの各要素は、マッピング内で多くても1回発生します。したがって、その観点から生じる用語は単数形になる傾向があります。関数を含む他の数学的理論や計算理論（例えば代数やラムダ計算）に渡って同じ単数形（あるいは少なくとも非複数形）の慣例が見られます。
私はいつも単数形のテーブル名を使いますが、すでに述べたように、最も重要なことは一貫性を保ち、すべての名前に同じ形式を使うことです。
複数のテーブル名について私が嫌いなのは、組み合わせた名前が非常に奇妙になる可能性があるということです。たとえば、Usersという名前のテーブルがあり、そのユーザーのプロパティを格納する場合は、UsersProperties..という名前のテーブルになります。
Zend Framework（PHP）などの特定のフレームワークを使用する場合は、テーブルクラスには複数形を、行クラスには単数形を使用することをお勧めします。
したがって、$ users = new Users（）というテーブルオブジェクトを作成し、行クラスをUserとして宣言したとすると、new User（）も呼び出すことができます。
テーブル名に単数形を使用する場合は、new UserTable（）のように行をnew UserRow（）にする必要があります。これは、テーブルにUsers（）オブジェクトを、行にUser（）オブジェクトを持つだけではなく、私にとっては不器用に見えます。
テーブル名が単数形であることを要求する「規約」はありません。
たとえば、評価プロセスで使用されるデータベースに "REJECTS"というテーブルがあり、プログラムの1回の実行で拒否されたレコードが含まれています。そのために複数形を使用しない理由はわかりません。 table（ "REJECT"と命名するのはただ面白い、あるいは楽観的過ぎるでしょう）。
他の問題（引用符）についてはSQL方言に依存します。 Oracleでは、テーブル名を引用符で囲む必要はありません。
両方のサイトで異なる論文があります、私はあなたがあなたの面を選ぶだけでよいと思います。個人的には、テーブルの命名にはPlurarを、列の命名にはもちろん単数形を使用します。
私はあなたがこれを読むことができる方法が好きです：
SELECT CustomerName FROM Customers WHERE CustomerID = 100;
本当に私たちはOOPを持っていて素晴らしいですが、ほとんどの人はリレーショナルデータベースを使い続けています。オブジェクトデータベースは使いません。リレーショナルデータベースのOOPの概念に従う必要はありません。
もう1つの例として、チームID、チームカラーだけでなくプレーヤーIDも保持するチームTeamsがあり、一定量のプレーヤーIDに対して同じチームIDとチームカラーがあります。
どのチームに所属していますか？
SELECT * FROM Teams WHERE PlayerID = X
Xチームの全プレーヤー？
SELECT * FROM Players INNER JOIN Teams ON Players.PlayerID = Teams.PlayerID WHERE Teams.TeamID = X
このすべての音はあなたにいいですか？
とにかく、W3Schoolsが使用している命名規則にも注目してください。
TABLE名は、テーブル構造の1つの定義です。 VIEWまたはQUERY名は、ビューの1つの定義または（1つ以上の）テーブルのクエリです。 TABLE、VIEW、またはQUERYには、以下のいずれかを含めることができます。
0レコード1レコード多数のレコード。
なぜあなたは単一のオブジェクト名の最後に 's'を付けたいのですか？これをオブジェクト名の最後に置くことで何を意味しますか。
区別したい場合は、 '_ tbl'を追加してください。ビューは '_vew'です（愚かな '_v'規約ではありません）。
最低3文字の接尾辞 - この議論を締めくくるのをやめます。
テーブルはDBオブジェクトです - 他に違いはありません。
3文字を保存しても、意味の明確さ以外に何も保存されません。
赤 ;-）
良い命名規則を探している間、私が名前をつけるべきであるように次の混乱が生じます：
1）acc テーブルが何を保持しているかの例：ユーザーのテーブル。それは常に複数形になるでしょう。だから、Users
2）acc。 recordが何を保持しているかの例：usersテーブルのレコードは1人のユーザーになります。 SO、User。
これで、users_rolesの問題が主になりました。ケース1：acc。最初の命名規則では、users_rolesこの名前が示すもの、ユーザーとその役割。
ケース2：acc。 2番目の命名規則、user_roleこの名前が提案するもの、ユーザー、およびその役割。
良い命名規則は、 エンティティの関係についての追加の考えを与えることです 、特に多対多の関係が保存されている場合。
ここでは、シナリオに従って、情報のセットとして識別します。
Usersテーブルでは、形成されたすべてのセットは一意のユーザーです。役割テーブルでは、形成されたすべてのセットは固有の役割です。ユーザーとロールの関係表では、格納された1-manyリレーションシップの概念を与えるさまざまなロールでユーザーのセットを形成できます。
I would prefer,
Users table => user
Roles table => role
users role relationship table => user_roles
私は、テーブルに "Employee"（実際には "Employees"）という名前を付けることで同じ問題を解決しました。予約語との衝突からできるだけ遠くに留まるようにしています。 「ユーザー」でさえも、私にとって不快に近いです。