テーブルとビューに名前を付けるとき、どの標準に従うべきですか?


20

テーブルとビューに名前を付けるとき、どの標準に従う必要がありますか?たとえば、テーブル名の先頭にtbl_のようなものを置くのは良い考えですか?ct_、lut_、codes_のような方法でコード/ルックアップテーブルを指定する必要がありますか?他にすべきこと/禁止事項はありますか?

私はMS SQL Serverを使用しており、多くのテーブルを持つ多くのデータベースを持っているので、いくつかの合理的なサポートを備えた標準として使用できるものがあると便利です。

回答:


29

OK、まずテーブル名の前にtblを置かないでください。これはテーブルです。すでにそのようになっています。これはハンガリー記法と呼ばれ、5年以上前に人々はそれをやめました。

それが何であるかに基づいてオブジェクトを呼び出すだけです。テーブルが従業員データを保持している場合、「従業員」と呼びます。コンピューターに関する情報を保持している場合は、「コンピューター」と呼びます。コンピューターを従業員にマッピングする場合、「EmployeeComputer」または「ComputerEmployee」と呼びます(個人的には「EmployeeComputer」の方が好きです)。

使用する実際の正しい命名規則はありません(ハンガリー記法を使用しない場合を除く)。オブジェクト名が重要であるということを意味する限り。


11
それに加えて、私は従業員の例を見てきたように、複数の名詞としてのテーブルの名前を入れないで下さい、Cumputers ...私たちは皆知っているテーブルが多くの行ではなく1 ..得ることになっている
マリアン

1
なぜテーブルのビューを作成するのですか?すべてのビューは、保存された選択ステートメントです。インデックス付きビューを使用していない限り、データはビューの背後で具体化されません。ビューを使用することはほとんどありません。確かにそうすることによるパフォーマンス上の利点はありません。
mrdenny

2
いくつかのテーブルを結合したり、コード値を人間が読める値に変換したりする場合にビューを使用します。2番目の状況は、似たような名前になってしまう状況です。
ベス・ホワイトゼル

2
:氏デニーズ答え、次の貢献者は、このことにより、バックアップされ dba4life.blogspot.com/2007/11/...

1
@Marian:クエリをより自然に読み、キーワードとの衝突を解決するため、複数形を使用します。私が使用した多くのシステムには注文エンティティがありました。複数形を使用すると、テーブル名が使用されordersなくorderなり、ユーザーになるたびにテーブル名を引用する必要がなくなります。これはgroup、他のキーワードにも適用されます。幸いなことに、共通のエンティティと衝突するキーワードはほとんどありません。
BillThor

13

パーミッションとグループ化の両方にスキーマ(おそらくSQLのネームスペースと考えてください)を使用します。「tbl」などの代わりに

  • Data.Thing
  • Data.ThingHistory
  • Data.Stuff

データスキーマにコードは入りません。データスキーマの外部に存在するテーブルはありません。もちろん、これを拡張して、必要に応じてLookupまたはStagingスキーマを使用できます。

使用するビューについてはvw、これはSQL Server 2000のテーブルと区別するためであり、現在はレガシーです


3
スキーマを推奨する場合は+1。これは、数百のテーブルで大規模なデータベースを維持しながら便利です。機能的なグループ化にもスキーマを使用します
。AdventureWorksdb

5

個人的に私はファノ・ベディンングの大ファンです、ここでは名前ではなく、別の有効な名前の始まりを許可しています。

次に、2つの名前の間のハミング距離は、複数の異なる文字よりも優れています。

はい、それはデジタル以前の時代からのルールですが、彼らは生活を楽にします。

そして、音声認識が真になると、サードネームは発音可能でなければなりません。


2
音声認識が真になると、とにかく怒ってしまいます。:-)
ベスホワイトゼル

テレ
トーン

1
音声認識が来ると、トラック運転手になります。それか狂った隠者。
-mrdenny

「ファノ・ベディンング」とは何か(おそらく例を挙げて)詳しく説明していただけますか?
ニックチャンマス

1
@NickChammas私は英語でこのシャノンファノコーディングと呼んでいると思います。
イアンサミュエルマクリーン長老

2

本当に個人的な好みと開発の容易さに要約されるため、「ベスト」な命名規則が実際に存在することはわかりません。私のアドバイスは、命名規則を選択してそれに従うことです。単語を下線で区切る場合は、すべてのデータベースオブジェクトで下線を使用します。camelCaseを使用する場合は、すべてのデータベースオブジェクトで使用してください。

私の店では、次のルールを順守しています。

単語はアンダースコアで区切り、すべて小文字を使用しています。
テーブル名は、dbo.person、dbo.invoiceを表しています。
多対多のテーブル名は、それらが何であるかを説明しています(mm対多のをマッピングされる多対多の関係を示します:dbo.person_mm_address。ユーザー定義のストアドプロシージャは、実行されるオブジェクトとアクションの両方を示します:usp_person_select 、usp_address_select_by_cityストアドプロシージャと同じルールに従って、ビューと関数はインデックス、テーブル、キー列(順番)、クラスター化/非クラスター化の表示を含みます:ix_person_last_name_first_name_nc

私の店でこれが使用されているからといって、これらのルールがあなたに合っているという意味ではありません。あなたとあなたの開発チームが便利で開発が容易であることに同意するものを選び、決めた命名規則を知って使用する文化を確立します。私たちの場合、これには、データベースで作成されたオブジェクトのコードレビューが含まれます。時間が経つにつれて、文書化された命名規則とピアコードレビューの組み合わせにより、規則からの逸脱がますます少なくなりました。

この「無回答」が何らかの形で役立つことを願っています。


2

私は何年も前からこれらに満足しています

  • テーブル名:スモールキャップとアンダースコア、単数形{customer、product}
  • 多対多リレーションのテーブル名:tablename1_tablename2:{customer_product}
  • ビュー:末尾にvが追加されたスモールキャップ{customerv、productv、product_groupv}
  • ストアドプロシージャ:テーブル名と関数{customer_select、customer_insert、customer_delete、customer_update}

安価な共有ホスティングパッケージがある場合は、データベース管理者サイト、da_users、da_questionsなど、すべてのオブジェクトの前にプロジェクトの略語を使用する必要があります。


ビューのためproduct_groupvではなくproduct_group_v、なぜですか(ビューとテーブルのこの区分を主張する場合)?
ypercubeᵀᴹ

@ypercubeは、アンダースコアを1つ入力するのが面倒で、入力ミスを犯しやすいためです。アンダースコアを使用して単語を読みやすくし、ビューをテーブルから分離するためにvを使用します。vは単語ではないため、アンダースコアを使用しないでください。
UğurGümüşhan
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.