sql - 複数形 - 中間テーブル 命名




テーブル名のジレンマ:単数型と複数型の名前 (20)

IMHO、テーブル名は顧客のように複数でなければなりません。

クラス名は、 Customersテーブルの行にマップする場合は、 Customerのように単数型でなければなりません。

アカデミアでは、表名は属性を格納するエンティティの単数型である必要があります。

私は名前の周りに角括弧を必要とするT-SQLは嫌いですが、私はUsersテーブルを特異なものに改名しました。

私の気持ちは、単数にとどまる方が正しいと感じていますが、大括弧は、括弧内に空白を含む列名のような望ましくないことを示しています。

私は滞在すべきか、または私は行くべきですか?


どのような規則で表に特異な名前が必要ですか? 私はいつもそれが複数の名前だと思った。

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

このサイトでは、
http://vyaskn.tripod.com/object_naming.htm#Tables

このサイトは意見が異なります(しかし、私はそれに同意しません):
http://justinsomnia.org/writings/naming_conventions.html

他の人が触れたように:これは単なるガイドラインです。 あなたとあなたの会社/プロジェクトのために働く大会を選び、それに固執する。 単数形と複数形、時には略語を切り替えることは時としてははるかに困難です。


他の人は "標準"のところまでかなり良い答えを出してきましたが、これを追加したかっただけです... "User"(または "Users")は実際にはテーブルに保持されているデータの完全な記述ではありません? テーブル名や特定性に夢中になるわけではありませんが、おそらく "Widget_Users"(ここでは "Widget"はアプリケーションやWebサイトの名前)のようなものが適切でしょう。


可能な選択肢:

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

ブラケットを使用するIMOは技術的には最も安全ですが、少し面倒です。IMOは、6つのうちの6つです。あなたのソリューションは、個人的な/チームの好みに変わります。


特異な。 私は、一連のユーザ行表現オブジェクト 'users'を含む配列を呼び出しますが、テーブルは 'user table'です。 テーブルには、それが含まれている行のセットだけであると考えると、間違っています。 テーブルはメタデータであり、行セットは階層的にテーブルに関連付けられていますが、テーブル自体ではありません。

私はもちろん、ORMを使用しています。複数のテーブル名で書かれたORMコードが馬鹿に見えるようになります。


特異な。 私は最も論理的な議論を購入しません - すべての人は自分の好みが最も論理的だと思っています。 あなたが何をしていても混乱ですが、ただの大会を選び、それに固執してください。 非常に不規則な文法やセマンティクス(通常の話し言葉や文章)を非常に規則的な(SQL)文法と非常に特殊なセマンティクスでマッピングしようとしています。

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

したがって、 AppUser関係は、どのエンティティがAppUsersます。

AppUserGroup関係は、どのエンティティがAppUserGroupsあるかを教えてくれます

AppUser_AppUserGroupリレーションは、 AppUsersAppUserGroupsがどのように関連しているかを示します。

AppUserGroup_AppUserGroupリレーションは、 AppUserGroupsAppUserGroupsがどのように関連しているかをAppUserGroupsます(グループのグループメンバ)。

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

私のコードでは、その後、データベーススキーマでは、私は単数型を使用します。 テキストの説明では、読みやすさを高めるために複数形を使用します。次に、フォントなどを使用して、複数の表/関係名を区別します。

私はそれを厄介だがシステマティックなものと考えるのが好きで、私が表現したいと思う関係のために、常に体系的に生成された名前があります。私にとっては非常に重要です。


私は、エンティティリレーションダイアグラムでは、エンティティを単数であるクラス名に類似した単数名で反映する必要があるという確信を持っています。 インスタンス化されると、その名前はインスタンスを反映します。 したがって、データベースでは、エンティティをテーブル(エンティティまたはレコードの集合)にすると、複数のものになります。 エンティティ、ユーザーはテーブルユーザーになります。 ユーザーの名前をEmployeeに改めることができるかもしれない、あるいはあなたのシナリオにもっと適用できる名前を示唆した人たちには私は同意するだろう。

これは、レコードのグループから選択しているので、SQLステートメントでより意味をなさないし、テーブル名が特異である場合、それはうまく読み込まれません。


私は、英語では単数形であるような無名の名詞を使うことを好む。

テーブル名の数を変えると正書法上の問題(他の多くの答えが示すように)が発生しますが、テーブルには通常複数の行が含まれているため、意味的に穴がいっぱいです。 これは、大文字と小文字を区別して名詞を使用する言語を考えれば、より明らかです。

私たちは通常行を使って何かをしているので、その名前を訴訟事件に入れてはどうでしょうか? 私たちが読んでいる以上に書いているテーブルがあれば、その名前をdativeに入れてみましょう。 それ何かのテーブルです、なぜgenitiveを使用しないのですか? 表は、その状態や使用方法に関係なく存在する抽象コンテナとして定義されているため、これは行いません。 正確で絶対的な意味論的理由なしに名詞を変えてしまうのはうんざりです。

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


私は単なるテーブル名のファンです。なぜなら、彼らはCASE構文を使って私のERダイアグラムを読みやすくしていますが、これらの応答を読めば、決してうまく捕らえられないという気持ちが出てきます。 私は個人的にそれを愛しています。 特異な表名を使用したり、関係動詞にアクション動詞を追加したり、すべての関係について良い文章を作成したりするときに、モデルの読みやすさの例に関する良い例があります。 それは20テーブルのデータベースのすべての過剰な部分ですが、何百ものテーブルと複雑なデザインのDBを持っている場合、あなたの開発者はどのように読みやすいダイアグラムなしでそれを理解することができますか?

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

プレフィックステーブルやビューについては、私は絶対にその練習が嫌いです。 人に悪い情報を与える前に、情報を全く与えない。 誰かがオブジェクトのためのDBを参照することは非常に簡単にビューからテーブルを伝えることができますが、私はtblUsersという名前のテーブルが何かの理由で私は古いコードを壊さないように統一されたビューで、私は今tblUsersという名前のビューを持っています。 この時点で私は2つの魅力的でないオプションを残しています。一部の開発者を混乱させるかもしれないtbl接頭辞を付けたビューを残すか、中間層またはアプリケーションを新しい構造や名前のviewUsersを参照するように書き直すように強制します。 それはビューIMHOの価値の大部分を無効にします。


私は単数形でも複数形でも、綴りが同じ表名には名詞だけを使用します。

ムーズ魚の鹿の航空機あなたはパンツのショートパンツ眼鏡のはさみ種の子孫


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

私は特異なテーブル名の議論を理解することができますが、私にとっては複数の意味があります。 表名は通常、表に含まれるものを記述します。 正規化されたデータベースでは、各テーブルには特定のデータセットが含まれています。 各行はエンティティであり、テーブルには多数のエンティティが含まれています。 したがって、テーブル名の複数形。

車のテーブルは車の名前を持ち、各列は車です。 table.field方法でフィールドと一緒にテーブルを指定することがベストプラクティスであり、特異なテーブル名を持つ方が読みやすくなることは認めます。 しかし、以下の2つの例では、前者のほうが意味があります。

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

正直言って、私はその問題について私の立場を再考し、私が開発している組織が実際に使っている慣習に頼っています。 しかし、私は私の個人的な慣習のために、私は複数のテーブル名に固執すると思います。 私にはもっと意味があります。


私は複数のテーブル名が好きではありません。なぜなら英語の名詞は数えられない(水、スープ、現金)か、あるいは意味を変化させるからです(鶏肉と鶏肉、肉と鳥)。 私はまた、テーブル名やカラム名の省略形の使用を嫌っています。これは、すでに急な学習曲線に余分な勾配が加わるためです。

皮肉なことに、私はUser (Transac-SQL)のためにUserを例外にしてUserと呼ぶかもしれません。なぜなら私はテーブルのまわりで大括弧を使いたくないから好きではないからです。

ChickenIdChickensIdではなくIDとしてすべてのID列に名前を付けることも好きです(これについて複数の人は何をしていますか?)。

これはすべて、データベースシステムに対して適切な敬意を払っていないためですJava's習慣や怠け者などのOO命名規則から1つのトリックポニー知識を再適用しています。 複雑なSQLのIDEサポートが改善されたことを願っています。


私個人は、複数の名前を使用してセットを表現することを好みます。

この瞬間、私は会社のデータモデルを定義するために単数形の名前を使用しています。職場の人のほとんどがそれに悩まされているからです。 時には、単にあなたの個人的な好みを課す代わりに、すべての人に人生を簡単にする必要があります。 (これは、このスレッドでは、名前付けテーブルの "ベストプラクティス"であるべきかどうかを確認する方法です)

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

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


簡単な例として、これについてはどうですか?

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

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

後者のSQLは、前者よりも見知らぬ音です。

私は単数に投票します。


これは少し冗長かもしれませんが、私は慎重であることを提案します。テーブルの名前を変更することは必ずしも悪いことではありませんが、標準化はそれだけです。このデータベースはすでに存在しており、おそらく2つ以上のテーブルで構成されているとすれば、より良い目標になることを提案したいと思います。

データベース全体を標準化したり、少なくともその目的に向かって作業するつもりでない限り、テーブル名はちょうど氷山の一角にすぎず、手近な作業に集中していると思われます。あなたの最善の利益 -

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

my2cents ---


システムtables/viewsサーバ自体の(SYSCAT.TABLESdbo.sysindexesALL_TABLESinformation_schema.columns、など)はほとんど常に複数です。私は一貫性のために私は彼らのリードを追うだろうと思う。


他の人がここで述べたように、慣習は、使いやすさと可読性を高めるためのツールでなければなりません。開発者を拷問するためのシャックルやクラブとしてではありません。

つまり、私の個人的な好みは、表と列の両方に単一の名前を使用することです。これはおそらく私のプログラミングの背景から来るでしょう。クラス名は、ある種のコレクションでない限り、一般的に単数型です。私の心の中では、問題のテーブルに個々のレコードを保管したり読んだりしているので、単数形が私には意味があります。

このプラクティスでは、オブジェクト間に多対1の関係を格納するテーブル名を複数用意しておくこともできます。

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

私は限られた方法で接頭辞を使うのが好きです(テーブル名はtbl、proc名はsp_など)。また、私はCamelBackの名前を強調するのが好きです。なぜなら、名前を入力するときには常に_の代わりに+を打つことになるからです。他の多くの人は同意しない。

ここでは、命名規則ガイドラインの別の良いリンクがありhttp://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/ : http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

あなたの大会における最も重要な要素は、問題のデータベースとやり取りする人々にとって意味があることです。命名規則に関しては、「すべてを支配する1つの環」はありません。


私のテイクは、あなたのコンテナをどのように定義するかによって、セマンティクスになります。例えば、「リンゴの袋」または単に「リンゴ」または「リンゴバッグ」または「リンゴ」。

例:「カレッジ」テーブルには0以上のカレッジを含めることができます「カレッジ」には0人以上の同僚を含めることができるテーブル

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

私の結論はどちらかというと上手ですが、テーブルを参照する際にあなた(またはそれとやりとりしている人)がどのようにアプローチするかを定義しなければなりません。"axテーブル"または "xsのテーブル"


私はいつもそれがダムのコンベンションだと思った。私は複数のテーブル名を使用します。

(私は、ORMコードジェネレータが単数名から複数の名前を生成する方が簡単であるため、オブジェクト&コレクションクラスを生成する方がORMコード生成者にとってより簡単になると考えています)


私は一度Userテーブルに "Dude"を使用しました。同じ短い文字数、キーワードとの矛盾はなく、一般的な人間への参照です。もし私がコードを見ることができる邪魔な頭を心配しなければ、私はそれをそのままにしていたでしょう。





naming-conventions