回答:
OK、まずテーブル名の前にtblを置かないでください。これはテーブルです。すでにそのようになっています。これはハンガリー記法と呼ばれ、5年以上前に人々はそれをやめました。
それが何であるかに基づいてオブジェクトを呼び出すだけです。テーブルが従業員データを保持している場合、「従業員」と呼びます。コンピューターに関する情報を保持している場合は、「コンピューター」と呼びます。コンピューターを従業員にマッピングする場合、「EmployeeComputer」または「ComputerEmployee」と呼びます(個人的には「EmployeeComputer」の方が好きです)。
使用する実際の正しい命名規則はありません(ハンガリー記法を使用しない場合を除く)。オブジェクト名が重要であるということを意味する限り。
orders
なくorder
なり、ユーザーになるたびにテーブル名を引用する必要がなくなります。これはgroup
、他のキーワードにも適用されます。幸いなことに、共通のエンティティと衝突するキーワードはほとんどありません。
パーミッションとグループ化の両方にスキーマ(おそらくSQLのネームスペースと考えてください)を使用します。「tbl」などの代わりに
データスキーマにコードは入りません。データスキーマの外部に存在するテーブルはありません。もちろん、これを拡張して、必要に応じてLookupまたはStagingスキーマを使用できます。
使用するビューについてはvw
、これはSQL Server 2000のテーブルと区別するためであり、現在はレガシーです
個人的に私はファノ・ベディンングの大ファンです、ここでは名前ではなく、別の有効な名前の始まりを許可しています。
次に、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
私の店でこれが使用されているからといって、これらのルールがあなたに合っているという意味ではありません。あなたとあなたの開発チームが便利で開発が容易であることに同意するものを選び、決めた命名規則を知って使用する文化を確立します。私たちの場合、これには、データベースで作成されたオブジェクトのコードレビューが含まれます。時間が経つにつれて、文書化された命名規則とピアコードレビューの組み合わせにより、規則からの逸脱がますます少なくなりました。
この「無回答」が何らかの形で役立つことを願っています。
私は何年も前からこれらに満足しています
安価な共有ホスティングパッケージがある場合は、データベース管理者サイト、da_users、da_questionsなど、すべてのオブジェクトの前にプロジェクトの略語を使用する必要があります。
product_groupv
ではなくproduct_group_v
、なぜですか(ビューとテーブルのこの区分を主張する場合)?