1647

学界では、テーブル名は属性を格納するエンティティの単数形にする必要があるとされています。

名前を角かっこで囲む必要がある T-SQL は嫌いですが、テーブルの名前Usersを単数形に変更し、テーブルを使用する人に角かっこを使用する必要があることを永久に宣告しました。

私の直感では、単数形にとどまる方が正しいと思いますが、角かっこは、列名にスペースが含まれているなどの望ましくないものを示しているとも感じています.

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

4

41 に答える 41

2037

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

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

理由2。（快適）。複数形よりも単数形の方が簡単に出てきます。オブジェクトは不規則な複数形を持つことも、まったく複数形にならないこともありますが、常に単数形になります（ニュースなどのいくつかの例外を除く）。

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

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

  • 1.注文
  • 2.OrderDetail

に比べ：

  • 1.OrderDetails
  • 2.注文

理由4（単純さ）。すべてをまとめると、テーブル名、主キー、関係、エンティティクラス...は、2つ（単数クラス、複数テーブル、単数フィールド、単数形-複数形master-detail）ではなく、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 = 103

3文字、3バイト、3回の追加キーボードヒットを節約しました:)

そして最後に、次のような予約名を台無しにしたものに名前を付けることができます。

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

または、悪名高い角かっこを使用します[ユーザー]

于 2011-04-30T10:56:16.553 に答える
274

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

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

私の新しい経験則は、オブジェクトに変換されたらどのように見えるかを判断することです。

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

于 2008-12-03T21:09:15.450 に答える
264

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

于 2008-12-03T19:31:01.157 に答える
258

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

テーブル名の数字を変えると正書法の問題が発生しますが (他の多くの回答が示すように)、テーブルには通常複数の行が含まれているため、そうするのを選択すると、意味的に穴がいっぱいになります。これは、大文字小文字に基づいて名詞を変化させる言語を考えると、より明白になります (ほとんどの場合)。

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

活用されていない名詞を使用することは、単純で、論理的で、規則的で、言語に依存しません。

于 2010-10-08T20:53:37.653 に答える
135

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

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

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

このサイトは同意しません（しかし私は同意しません）：http：
//justinsomnia.org/writings/naming_conventions.html

他の人が述べたように：これらは単なるガイドラインです。あなたとあなたの会社/プロジェクトに適した慣習を選び、それを守りましょう。単数形と複数形、または場合によっては省略形の単語を切り替えると、場合によってはさらに悪化します。

于 2008-12-03T18:13:04.963 に答える
94

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

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

対。

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

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

私は単数形に投票します。

于 2009-04-04T01:24:47.587 に答える
66

私は、エンティティ関係図では、クラス名が単数形であるのと同様に、エンティティは単数形の名前で反映されるべきであると固く信じています。インスタンス化されると、名前はそのインスタンスを反映します。したがって、データベースでは、テーブル (エンティティまたはレコードのコレクション) に作成されたエンティティは複数形になります。エンティティ、User をテーブル Users にします。ユーザーという名前を従業員またはあなたのシナリオにより適したものに改善できる可能性があると提案した他の人に同意します。

これは、レコードのグループから選択していて、テーブル名が単数形の場合、うまく読み取れないため、SQL ステートメントではより意味があります。

于 2009-01-02T23:38:53.480 に答える
45

私は、テーブル名と任意のプログラミング エンティティに対して単数形を使用します。

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

これは、複数性を際立たせるのに非常に役立ちます。また、物の集まりがどのように見えるかをプログラムで簡単に判断できます。

したがって、私のルールは次のとおりです。ORM にも役立ちます。

于 2008-12-05T01:15:51.303 に答える
40

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

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

于 2009-04-30T21:03:40.927 に答える
39

特異な。私はどちらが最も論理的かという議論には賛成しません。誰もが自分の好みが最も論理的だと考えています。何をしてもめちゃくちゃです。慣習を選んでそれを守りましょう。非常に不規則な文法と意味論 (通常の話し言葉と書き言葉) を持つ言語を、非常に特殊な意味論を持つ非常に規則的な (SQL) 文法にマッピングしようとしています。

私の主な主張は、テーブルを集合としてではなく、関係として考えているということです。

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

AppUserGroupリレーションは、どのエンティティがAppUserGroups

関係は、とがAppUser_AppUserGroupどのように関係しているかを教えてくれます。AppUsersAppUserGroups

関係は、とがAppUserGroup_AppUserGroupどのように関係しているかを教えてくれます(つまり、グループのグループ メンバー)。AppUserGroupsAppUserGroups

言い換えれば、実体とそれらがどのように関連しているかについて考えるとき、私は関係を単数で考えますが、もちろん、コレクションまたはセット内の実体について考えるとき、コレクションまたはセットは複数です。

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

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

于 2010-12-21T12:49:12.437 に答える
31

また、複数形も使用しますが、前述のユーザーのジレンマにより、角括弧のアプローチを採用しています。

これは、コード アーティファクトのUsersコレクションがUserオブジェクトのコレクションであるのと同じように、 UsersテーブルがUser値のコレクションであるという基本的な理解に基づいて、データベース アーキテクチャとアプリケーション アーキテクチャの両方に統一性を持たせるために行います。

データ チームと開発者が同じ概念言語 (常に同じオブジェクト名ではありませんが) を話すことで、彼らの間でアイデアを簡単に伝えることができます。

于 2008-12-03T20:23:56.417 に答える
24

私は個人的に、セットを表すために複数形の名前を使用することを好みます。それは、私のリレーショナル マインドにとって「聞こえる」だけです。

まさに今、会社のデータ モデルを定義するために単数形の名前を使用しています。これは、職場のほとんどの人が単数形の名前の方が使いやすいと感じているからです。個人的な好みを押し付けるのではなく、すべての人にとって生活を楽にする必要がある場合があります。（これが、テーブルに名前を付けるための「ベストプラクティス」であるべきことを確認するために、このスレッドにたどり着いた方法です）

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

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

于 2013-02-26T18:39:51.007 に答える
19

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

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

車のテーブルには車という名前があり、各行は車です。テーブルとフィールドをtable.field同じ方法で指定するのがベスト プラクティスであり、テーブル名が単数の方が読みやすいことは認めます。ただし、次の 2 つの例では、前者の方が理にかなっています。

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

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

于 2010-09-17T20:10:33.747 に答える
19

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

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

于 2009-01-02T23:48:27.063 に答える
16

英語の名詞の中には数えられないもの (water、soup、cash) や、数えられるようにすると意味が変わるもの (chicken vs a Chicken、meat vs bird) があるため、複数形のテーブル名は好きではありません。また、テーブル名や列名に略語を使用することも嫌いです。これを行うと、すでに急勾配の学習曲線にさらに勾配が追加されるからです。

皮肉なことにUser、例外を作成してUSER (Transac-SQL)Usersのために呼び出す可能性があります。これは、必要がなければ、テーブルの周りに角かっこを使用するのも好きではないためです。

Idまた、すべての ID 列に, not ChickenIdorという名前を付けるのも好きChickensIdです (複数の人はこれについて何をしますか?)。

これはすべて、私がデータベース システムを適切に尊重していないためです。私は、Java の習慣や怠惰などの OO 命名規則から得たワントリック ポニーの知識を再適用しているだけです。複雑な SQL に対する IDE のサポートが改善されればと思います。

于 2008-12-03T19:28:09.897 に答える
15

スクリプトを作成するときは、名前の周りに [ ] を要求し、適切な場合はスキーマ修飾子を要求します。主に、SQL 構文による将来の名前の取得に対する賭けをヘッジします。 

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

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

于 2008-12-03T19:24:11.123 に答える
13

tables/viewsサーバー自体のシステム( SYSCAT.TABLES、dbo.sysindexes、ALL_TABLES、information_schema.columnsなど) は、ほとんどの場合複数形です。一貫性を保つために、私は彼らのリードに従うと思います。

于 2008-12-03T20:20:57.187 に答える
12

表: 複数形

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

モデル: 単数形

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

コントローラー: 複数

http://myapp.com/usersは複数のユーザーを一覧表示します。

とにかくそれが私の見解です。

于 2009-11-25T21:23:00.943 に答える
12

それが私が教えられたものだからです。ただし、最近新しいスキーマを作成しているときに、久しぶりに、この規則を維持することに積極的に決めました。理由は... 短いからです。すべてのテーブル名の最後に「s」を追加することは、すべてのテーブル名の前に「tbl_」を追加するのと同じくらい役に立たないように思えます。

于 2010-10-21T01:37:17.703 に答える
12

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

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

学界では覚えていますが、推薦は特異なものでした。

たとえば、次のように言います。

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

おそらく b/c それぞれIDが特定の単一の行から選択されます...?

于 2012-11-02T21:48:21.003 に答える
12

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

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

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

于 2009-01-02T23:50:58.603 に答える
10

私はかつて User テーブルに "Dude" を使用しました - 同じ短い文字数で、キーワードとの競合はなく、依然として一般的な人間への参照です。コードが見られるかもしれない息苦しい頭を気にしていなければ、そのままにしていたでしょう。

于 2012-11-30T16:28:55.490 に答える
9

可能な代替案：

  • テーブルの名前をSystemUserに変更します
  • 角かっこを使用する
  • 複数のテーブル名を保持します。

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

于 2008-12-03T18:15:08.577 に答える
9

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

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

実用的な一貫性は、時には最良の基準です... :)

my2cents ---

于 2008-12-03T18:33:13.207 に答える
9

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

例: 「大学」テーブルには 0 個以上の大学を含めることができます 「大学」のテーブルには 0 個以上の大学を含めることができます

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

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

于 2011-10-04T18:23:23.380 に答える
8

他の人がここで述べたように、規約は使いやすさと読みやすさを向上させるためのツールであるべきです。開発者を苦しめるための束縛や棍棒としてではありません。

とはいえ、私の個人的な好みは、テーブルと列の両方に単数形の名前を使用することです。これはおそらく私のプログラミングのバックグラウンドから来ています。クラス名は、ある種のコレクションでない限り、一般的に単数形です。私の考えでは、問題のテーブルに個々のレコードを保存または読み取っているので、singular は私にとって理にかなっています。

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

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

私は限定された方法で接頭辞を使用するのが好きです (テーブル名には tbl、proc 名には sp_ など)。また、名前を入力するときに常に _ ではなく + を押すことになるため、アンダースコアよりも CamelBack の名前を好みます。他の多くの人は同意しません。

命名規則のガイドラインに関する別の適切なリンクは次のとおりです。

規則で最も重要な要素は、対象のデータベースを操作する人々にとって意味のあるものであることを忘れないでください。命名規則に関しては、「すべてを支配する 1 つのリング」はありません。

于 2008-12-03T19:11:59.587 に答える
7

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

（そのポリシーの背後にある理論的根拠は、ORMコードジェネレーターがオブジェクトおよびコレクションクラスを生成しやすくすることです。これは、単一の名前から複数の名前を生成する方が、その逆よりも簡単だからです）

于 2008-12-03T18:17:47.183 に答える
7

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

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

于 2013-02-18T04:32:25.273 に答える
7

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

ヘラジカ 魚 鹿 航空機 あなた パンツ ショートパンツ 眼鏡 はさみ 種 子孫

于 2012-05-27T18:51:53.647 に答える
5

ガイドラインはまさにその通りです。それは「石に固定」されていないので、それらを無視できるオプションがあります。

複数のテーブル名を使用する方が論理的に直感的だと思います。結局のところ、テーブルはエンティティのコレクションです。言及された他の選択肢に加えて、私は一般的にテーブル名にプレフィックスを表示します...

  • tblUser
  • tblThis
  • tblThat
  • tblTheOther

私はこれが進むべき道であることを示唆していません、私はまた私が嫌うテーブル名で多くのスペースが使われているのを見ます。私は？のようなばかげた文字でフィールド名に出くわしたことさえあります。このフィールドが質問に答えると言うかのように。

于 2008-12-03T18:19:57.790 に答える
5

単数形の名前を使用する理由について、私の意見を述べます。

たとえば、ユーザーからすべてのフィールドを取得する必要があります。

-- 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'

もちろん、複数形も同じ意味で使えますが、私の脳が読むには、それが正しい方法だと本当に思います。

于 2009-01-20T13:57:13.533 に答える
5

テーブルの SQL 定義は、実際にはコレクションではなく、テーブルの 1 つの潜在的な行の定義です。したがって、その定義で使用される名前は、コレクションの名前ではなく、行のタイプを指定する必要があります。複数形を好む人は、英語のステートメントで読みやすいという理由で複数形を好む人は、より論理的に考え始め、実際にテーブルを使用することに関連するすべてのロジックとプログラミング コードを検討する必要があります。これらのコメントで言及されている、単一のテーブル名を使用するための非常に正当な理由がいくつかあります。これらには、複数形のテーブル名を使用してはならない非常に正当な理由が含まれています。「よく読んでいる」というのは、まったく理由にならないはずです。

于 2012-11-30T16:24:34.540 に答える
4

行けば困るが、泊まれば倍になる。

予約語である可能性のあるものにちなんでテーブルに名前を付けるよりも、複数形以外の想定される命名規則に反対したいと思います。

于 2008-12-03T20:16:01.267 に答える
3

私は常に単数形のテーブル名を使用していますが、既に述べたように、最も重要なことは一貫性を保ち、すべての名前に同じ形式を使用することです。

複数のテーブル名について私が気に入らないのは、結合された名前が非常に奇妙になる可能性があることです。たとえば、名前が付けられたテーブルがUsersあり、ユーザーのプロパティを保存する場合、これはUsersProperties...という名前のテーブルになります。

于 2009-11-23T14:34:39.593 に答える
3

テーブル名が単数形であることを要求する「規則」はありません。

たとえば、評価プロセスで使用されるデータベースに「REJECTS」というテーブルがあり、プログラムの1回の実行で拒否されたレコードが含まれていましたが、そのテーブルに複数形を使用しない理由はありません（「 REJECT" というのはただの冗談か、楽観的すぎるだけだったでしょう)。

他の問題（引用）については、SQL方言に依存します。Oracle では、テーブル名を引用符で囲む必要はありません。

于 2008-12-03T19:06:57.007 に答える
3

両方のサイトに異なる論文があります。どちらかを選択するだけでよいと思います。個人的には、テーブルの命名には Plurar を、列の命名にはもちろん単数形を好みます。

私はあなたがこれをどのように読むことができるかが好きです:

SELECT CustomerName FROM Customers WHERE CustomerID = 100;

実際、私たちは OOP を持っており、それは素晴らしいことですが、ほとんどの人はリレーショナル データベースを使い続けており、オブジェクト データベースは使用していません。リレーショナル データベースの OOP の概念に従う必要はありません。

別の例として、TeamID、TeamColor だけでなく PlayerID も保持するテーブル Teams があり、一定量の PlayerID に対して同じ teamID と TeamColor を持ちます...

選手はどのチームに所属していますか?

SELECT * FROM Teams WHERE PlayerID = X

Xチームの全プレイヤー?

SELECT * FROM Players INNER JOIN Teams ON Players.PlayerID = Teams.PlayerID WHERE Teams.TeamID = X

これはすべてあなたにとって良い音ですか？

とにかく、W3Schools で使用されている命名規則も参照してください。

http://www.w3schools.com/sql/sql_join_inner.asp

于 2013-08-30T14:07:16.997 に答える
3

TABLE 名は、テーブル構造の 1 つの定義です。VIEW または QUERY 名は、(1 つまたは複数の) テーブルのビューまたはクエリの 1 つの定義です。TABLE、VIEW、または QUERY には、次のいずれかを含めることができます。

0 レコード 1 レコード 多数のレコード。

いったいなぜ、単一のオブジェクト名の最後に「s」を付けたいのでしょうか? オブジェクト名の末尾にこの「s」を付けて何を意味しますか?

区別したい場合は、'_tbl' を追加します。ビューは '_vew' です (ばかげた '_v' 規則ではありません)。

最低 3 文字の接尾辞 - この議論が行き詰まるのを防ぎます。

テーブルは DB オブジェクトであり、他と何ら変わりはありません。

3文字の節約は、意味の明確さを除いて何も節約しません.

赤 ;-）

于 2012-04-09T20:39:20.963 に答える
2

Zend Framework (PHP) などの特定のフレームワークを使用する場合は、テーブル クラスに複数形を使用し、行クラスに単数形を使用するのが賢明です。

たとえば、テーブル オブジェクト $users = new Users() を作成し、行クラスを User として宣言すると、new User() も呼び出すことができます。

テーブル名に単数形を使用する場合、行が new UserRow() である new UserTable() のようなことを行う必要があります。これは、テーブル用のオブジェクト Users() と行用の User() オブジェクトを使用するよりも不器用に見えます。

于 2008-12-03T20:11:06.957 に答える
1

テーブルに「Employee」（実際には「Employees」）という名前を付けることで、同じ問題を解決しました。私は、予約語の可能性があるものとの衝突からできるだけ遠ざかるようにしています。「ユーザー」でさえ、私にとって不快なほど近くにあります。

于 2008-12-03T19:33:52.897 に答える