リファレンスデータベースオブジェクトの命名

参照は、本明細書仕様ではなく、標準的ではありません。それは私の個人的な見解や提案を表しており、通常の条件の下でのみルールを考え、あなたは自由に実際の状況に応じて変更することができます。

入門

コーディング標準優秀なプログラマーの基本的な資質は、しかし、多くの人が名前の非常に集中プログラム変数、メソッド、クラスがあるが、彼らは同様に重要なデータベースオブジェクトの命名を無視しています。この多くの技術記事や情報と組み合わせるの記事だけでなく、データベースオブジェクトの命名規則の開発における私自身の経験では、いくつかの基準を提供することを望んで、いくつかの提案を前方に置きます。

注：「データベースオブジェクトの命名参照」と題するこの記事は、実際には、この記事では、私が唯一連帯して命名規則データベースを導入していないが、注意が必要なデータベースの設計と開発におけるいくつかの問題について説明します。

基本的な命名規則

表1.基本的なデータベースオブジェクトの命名

データベース・オブジェクト	接頭辞	例えば
表（テーブル）のフィールド（列）ビュー（ビュー）ストアドプロシージャ（ストアドプロシージャ）フリップフロップ（トリガー）インデックス（指数）主キー（主キー）、外部キー（外部キー）チェック制約（チェック制約）ユニーク制約のユーザ定義のデータ型を（ユーザ定義データ型）ユーザ定義関数（ユーザ定義関数）	ノーノー V PR TR ix_ PK_ fk_ ck_ uq_ UDT のFn	学生タイトル vActivity prDelOrder trOrder_D ix_CustomerID pk_Admin fk_Order_OrderType ck_TableColumn uq_TableColumn udtPhone fnDueDate

命名に合意

変数（プログラム内で宣言T-SQL変数）、プロセス（ストアドプロシージャやトリガなど）、エンティティ（テーブル、フィールド）は、それらが表すプロセス内のエンティティの意義と役割に基づくべきであると命名されています。

表2.良い名前と名前の悪い例

美名	悪い名前
@CurrentDate @ActivityCount @EquipmentType prCalculateTotalPrice	@D @ActNum @ET @prRunCalc

もう一つのよくある間違いは、唯一のコンピュータ指向の用語を使用するのではなく、そのようProcessRecordなど、同社のビジネスのための用語が曖昧名前で、説明は、CompleteOrderとして、ビジネス・プロセスとそれを置き換える必要があります。

単に要件に基づいている場合は、ビジネス名に記載された手順に従って、以下のような、非常に長くなることがあります。

prCountTotalAmountOfMonthlyPayments（毎月の給与の合計金額を計算）

prGetParentOrganizationalUnitName（親ユニットの名前を取得します）

この時点では、略語を使用して検討する必要があります。

月曜（月曜日）、12月（12月）：あなたは辞書で単語の省略形を見つけることができれば、のような、略語としてこれを使用します
あなたは（単語の最初の文字を除く）単語の母音を削除し、単語の略語に各単語の文字を繰り返しすることができます。たとえば、次のように電流= CRNT、住所= Adrを、エラー=のErr、平均=平均
略語の不一致（スピーチに通常は曖昧さ）を使用しないでください。例えば、B4（前）、xqt（実行）、4tran（Fortranの）

名前のテーブル、フィールド：

単数形のテーブル名、フィールド名または複数のテーブル名、フィールド名？

私たちはめったに我々は顧客、または顧客を取る必要があり、情報テーブルのゲストを保存するために、例えば、単数または複数のテーブル名に考慮されないかもしれませんか？私は、「SQL Server 2000のコレクション、」参照の時代からある次、単数形のテーブル名から提唱します：

表は、レコードのセットで構成されているので、あなたはそれに名前を付けるために、複数の名詞を使用する必要があります考えられてキャンプ複雑なテーブル名の使用を提唱。Customersテーブルには、顧客の集合であり、コレクションは、Customersテーブルにそれらを呼び出す必要がありますので、より多くのことを意味し、：彼らはしばしばという根拠を使用しています。あなたが唯一のクライアントを持っていますが、場合を除き、このデータベースを必要としません。

非公式の調査の著者によると、SQL Serverの開発者の四分の三は、単数形の名前をサポートしています。開発者は、顧客テーブルではなく、クライアントのコレクションよりも、顧客の集合体であると信じています。行のセットはならず、（その行のセット）セットの行になることができず、行セット（行セット）と呼ぶことにします。Customersテーブルがより明確に聞こえると言うことよりも、そして、通常議論する人々は、テーブルの単数形名を参照するために使用する際に、Customerテーブルを言います。

不要なテーブルの接尾辞を避けます

私は、我々はすべて知っていると思うこれらの二つの点：1、表には、データ情報を格納するために使用されています。2、テーブルは行の集合です。テーブルには、それに含まれるデータ情報を説明することができたのであれば、あなたは接尾辞は、上記の2点を反映追加する必要はありません。

GuestInfo、顧客情報を格納するために使用：練習、私はそのように命名テーブルの上に私の同僚のいくつかを見ました。この名前は、上記の点1で繰り返され、誰もがテーブルには、もともとの情報（情報を）保存したことを知っている、プラス余分情報は、その上にお客様のテーブル名を直接行う個人に等しいです。

テーブル保存されたフライト情報については、彼はFlightList命名されました。これは、順番に点2を繰り返す前に言わ命名され、テーブルにはとても自然、行の集合であるリスト（一覧）で、プラスサフィックスはないフライトは非常に良いという名前の、冗長リストを作ったのですか？ここでは、彼自身が明確な命名規則を策定していない、または2つの表は、どちらかの名前を付ける必要があります。両方のミックスをGuestList、FlightListいずれかGuestInfo、FlightInfoの名前ではなく。

接続テーブルで指定された多くの関係

ご存知のように、あなたが2つのエンティティ間の関係-多くを達成したい場合、あなたは解決テーブルそのうちの1つは3つのテーブルが必要です。学生はもちろん、学生の多くを持つことができ、コースの多くを選択することができます。対多の関係次の点を考慮して、これは学生の入学の古典的な問題です。このとき、上記の関係を達成するために、我々は（このテーブルは唯一のIDと学生IDプログラムを格納し、学生情報やコースの情報は、それぞれ自分のテーブルを提示）、解像度テーブルを必要とする表の名前は、提案された文言がありますテーブルを組み合わせた二つのテーブルの名前（比較表簡素化が長くない場合）、そのようなStudentCourse。したがって、学生の達成StudentIdという名前のこのテーブルのフィールド、CourseID（この表の複合主キーの両方を同時に接続Studentテーブルとコースのテーブルの外部キー、などと言うで名前の主キーと外部キーで）、およびクラス間の多くの関係は、当然のことながら、この関係はまた、このようなテーブルプラスACCESSLEVELフィールドの範囲D {読み取り専用、完全に禁止}、我々は、アクセスのレベルを達成することができますがStudentCourseするように余分な少し何かを、追加することができます。

大会/接尾辞の前にフィールド名

長い時間のためのデータベース開発は、とゆっくりになり、法律を働いた：多くのフィールドは、いくつかの共通の特徴を持っているということです。例えば、いくつかのフィールドは、時間の代表である（例えば、ポスト時間、審査時間など）、（そのような見解、コメントなど）いくつかの代表者の数、真と偽のタイプのいくつかの代表（例えば、ブログのエッセイは、ホームページに表示されるかどうか）。フィールドのこの同じタイプの場合、あなたはそれを識別するために、統一された接頭辞または接尾辞を使用する必要があります。

私たちはあなた、もう少しはっきりと見るためにいくつかの例を与えます。

私たちは、すべてのフォーラムに精通している、最後のメンバーのログインの時間を記録する必要性が、この時間は、ほとんどの人はLoginTimeまたはLoginDateという名前のこのフィールドを配置します。このとき、あいまいさを生産している：他の開発者のために、私たちはテーブルの内容を見ていない、唯一のフィールド名のテーブルを見れば時間があるので、ログインの数にLoginTimeを理解することは容易です常識、それが数です。

これを防ぐために、それは明確に定義する必要があります。すべてのフィールドは、エンドとして日に統一時間を表します。

私たちは、多くの場合、投稿の統計に必要な情報を返信、今回、開発者は多くの場合、そのように命名フィールドを移動します。ここでもPostAmount、PostTime、PostCount、による曖昧さの時間に、我々は最初のフィールド名としてPostTimeを使用して排除していません。次に、金額や回数は数えることができるが、それとの適切な意味を表し、？ここで、私はカウントを使用することをお勧めします。なぜ？あなたがAspの開発を行った場合、私たちはRecordCountプロパティを知っていると信じて、原則的に名前を付けるとき：つまり、自分の名前を作成しようとせずに大会の名称を使用して。Microsoftは数を示すためにカウントサフィックスを持っているので、なぜ我々はしないのですか？

だから、すべての数字は、フィールドが最後までとしてカウントすべきである表します。この概念を促進するために行う、そうで再生回数への訪問、ログインLoginCountのためとは、描きやすいです。

別の例として、我々はほとんど通常は画像のURLパスを保存し、データベース、写真、その他のバイナリデータに直接保存されません。記事を再生した場合には、物品管理システムでは、記録文書ソース]フィールドを使用します。リンクされたすべてのフィールドに代わって個人的勧告は、URLの最後です。したがって、IMAGEURLという名前のイメージパスフィールドは、記事のソース]フィールドに名前を付けることのSourceURLです。

最後の例は、私たちはしばしば、たとえば、このエッセイは、このエッセイがそうで下書きに保存されていない、ホームページに表示しないように、ブール値を使用する必要があります。また、マイクロソフトの提案によると、ブール値ではあるが、持っている、または缶の始まり。

私はエッセイの中に構築する必要があった場合は自宅のフィールドかどうかを示し、その名は大文字でなければなりません。IsOnIndex

同様の例は、私はほんの数典型的な例を言及するためにここにいます、私は満足されるより良いアイデアで役割を果たすことができるならば、我々は、自分自身で展開することができ、多くのです。

フィールドに名前を付けるときの注意すべき一つの問題

ユーザーID、のUserPassword、ユーザー名、UserPhoneなど：私は多くの開発者はあなたがユーザーと呼ばれるテーブルを持っている場合は、その後、彼は、このテーブルのフィールドに名前が付けられます、例えば、接頭辞としてテーブル名とそれをフィールドすることを好む発見しましたように。個人的にあなたがすでにこのテーブルは、その後、ユーザ情報に格納されたフィールドのいずれかをユーザーに向けなければなりませんかを正確に知っているので、これは、必要ではないと思われます。また、操作に参加しましょう、あなたのSQLコードは、[ユーザー] .UserName = Aritcle.ArticleAuthorこのようなコードは、[ユーザー] .nameの= Article.Authorとして実現することができるようにいくつかのより合理的な外観になります。

ここでは、特殊なケースもあり、外部キーテーブルが含まれています。この場合、私はそのようなので、上の区分、ユーザーIDとして、テーブル名+モードIDを使用する傾向があります。仮定テーブル条、その後、私は、IDという名前の主キーになり、ユーザテーブルユーザーを含む外部キーフィールドに、私は、ユーザーIDに名前を付けます。あなたは（C＃など）言語でオブジェクトを作成するときに、時には（データベースフィールド名に従ってフィールド、プロパティ名生成対象）コード生成器を使用するため、この理由は、その後、生成されたコードより規則的な数です。

テーブルの構築を検討する課題

だけでなく、データを格納するために使用されるデータベースは、あるデータの整合性と一貫性を維持するための責任を負わなければなりません

私はこれであると感じ、多くの開発者がデータベースを設計し見てきました：その名のと同じように、彼らの目にはデータベースの役割 - データのみを格納するために使用され、加えて主キーを構築しなければなりませんでした、何も...ない制約、インデックスなし、外部キー制約、無ビューではなく、さらに、ストアドプロシージャをチェックしません。

ここで、私は次のデータベースの設計をお勧めします。

あなたは、テーブル内の行を確保するためのコードを書きたい場合はユニークで、テーブルの主キーを追加します。
ライト・コードは、テーブルの別の列が一意であることを確認する場合は、表に制約を追加します。
値が一定の範囲にのみ属することができ、テーブルのコード列を書くと判断された場合は、チェック制約を追加します。
あなたが親に接続するためのコードを書きたい場合 - 子テーブル、リレーションシップを作成します。
あなたは、「テーブルの変更で親行は、子テーブルの行で共同関連の変更は、一度」有効になっているカスケード削除および更新を維持するためのコードを記述します。
あなたは、クエリへの参加の大規模な番号に電話したい場合は、ビューを作成します。
あなたがビジネスルールを完了するために、データベース操作のいずれかによって文を書きたい場合は、ストアドプロシージャを使用します。

注：ここで私はそう、フリップフロップは、データベースがすぐにあまりにも複雑になります証明慎重フリップフロップのチェーンも頭痛を内蔵していない場合は、より重要なのは、デバッグが困難トリガされ、フリップフロップについては言及しませんでした私は単純にトリガを使用しないことを好みます。

のテーブルを構築するためのアイデアを持つnullではありません

私はあなたが新しいフィールドを作成したい場合は、彼のアイデアは、テーブルの構築に多くの開発者があるときは、このことを発見：このフィールドはその後、裁判官にNullになり、デフォルトでは必ずしもNULLではないではないことはできない、そうでない場合は、[OK]を、このフィールドは、次のフィールドに進み、nullにすることができます。その結果、多くの場合、Nullを考えることができ、すべてのプライマリキーフィールドに加えてテーブルです。

ヌルまあ、プログラムは、ああ、間違いを犯すためにあなたが誤ってフィールドを失うことを忘れた場合、あなたがレコードを挿入すると、プログラムがまだ実行することができます簡単ではありませんが、「XXフィールドはnullにすることはできません」が表示されていないため、このような考えは、そこにある理由エラーメッセージ。

しかし、この結果は非常に深刻ですが、またあなたのプログラムが複雑になるようになり、あなたは手続き上のエラーを回避するために、いくつかの不要なNULL処理を行う必要があります。そのようなヌル注文の特定の値として、いくつかの重要なデータは、その後、我々はすべて知っている場合にも悪いことに、（例えば、加算、減算、乗算、除算など）の任意の値ヌル位相操作は、結果がnullの場合、結果は、その注文でありますまた、ヌル合計金額。

あなたは、次のコードを実行しようとすることができます。

結果としてNULL + 5を選択

あなたは、私がnullではないにフィールドを設定した場合でも、言うかもしれないが、それでもヌルプログラムで処理しなければならないように、それは、まだ空の文字列に許容可能です。、データベースはまた、あなたの強力な武器を与え、あなたはどちらの一つのフィールドはNULLにすることができますことを確認する必要がある場合、チェック制約である、また缶が空である、あなたが書くことができます忘れないでください。

ColumnNameにVARCHAR（50）NOT NULL制約ck_ColumnNameチェック（レン（ColumnNameに）> 0）

したがって、思考の合理的な方法は次のようにする必要があります：このフィールドはNULLではないデフォルトであり、これは非フィールドではないかどうかを確認、[OK]を、このフィールドはNULLではない、と次のフィールドでない場合は、nullではありません。

サンプルスクリプトのテーブルを構築します

私は、テーブルの資料では、このように書かれている私自身の個人的な空間を作成しています：

この記事では、作成した表条
（
    同上のIntアイデンティティ（1、1）NULLでない、
    タイトルVARCHAR（50）NOTユニークのNULL制約uq_ArticleTitle、
    キーワードVARCHAR（50）NOT NULL、
    抽象VARCHAR（500）NOT NULL、
    著者VARCHAR（50）デフォルトをnullではありません'張Zaiyang'、
    タイプ0 TINYINT（タイプ（0,1,2）での）デフォルトNOT NULL制約ck_ArticleTypeチェック、 - 0、元; 1、コンパイル; 2、翻訳
    IsOnIndexビットNOT NULLデフォルト1、 -かホーム
    コンテンツテキストNULLではない、
    ソースコードVARCHAR（100）ヌル、 -プログラムソースコードのダウンロードパス
    ソースVARCHAR（50）NOT NULLデフォルトの 'TraceFact'、 - 記事のソース
    SrcUrl VARCHAR（150）ヌル、 - URLの記事の源である
    デフォルトのGetDateのDateTime NOT NULLを（POSTDATE）、
    再生回数のInt NOT NULLデフォルト0、
    CLASSIDのInt NOT NULL -外部キーフィールドには、記事のカテゴリが含ま

    制約pk_Article主キー（ID）を-主キーを作成します
）

私たちは、ここで私は、物品の種類が唯一の0,1,2にすることができることを保証するために、チェック制約を使用しています、見ることができます。ここでは、私が命名規則チェック制約であると言いたい：チェック制約にもかかわらず、フィールドのためのものであるが、同じデータベース内に、同じ名前のチェック制約を持つことはできません。したがって、このような本例のスクリプトck_ArticleTypeとして、それに名前を付けることck_ +テーブル名+カラム名を使用することをお勧めします。

また、私はまた、記事のタイトルの一意性を保証するために、ユニーク制約を使用していました。これは私のブログの記事のテーブルであるので、繰り返しのタイトルは、Insert文を使用する場合、挿入重複した値を避けるため、表示されません。同様の制約をチェックし、ここでの命名規則は次のとおりです。uq_ +テーブル名+カラム名。

プライマリキーの名前

pk_TableNameの主キーに名前を付け、SQL Serverの既定の仕様に応じて（あなたは、Enterprise Managerを使用して主キーを作成するときに、主キーのデフォルト名は、生成されました）。SQL Serverに付属2000 Northwindサンプルデータベースには、このようなEmployeeTerritoriesテーブルとして（あなたは時々、Enterprise Managerの2つのフィールドの前のテーブルには、キーアイコンが表示されます表示されます、テーブルの主キーではなく、フィールドであり、、フィールドの主キーであることが誤解されるだろう）、その2つの主キーは、間違った実際に、1つのプライマリキーがありますが、テーブルの上に2つのフィールドが含まれている、それは多くの場合、その複合主キーと言われています。より鮮やかな理解を持つためには、前述した、多くの人がテーブルStudentCourse例に参加する複合主キーのSQL文の確立を見てみましょう。

表StudentCourseが変更
制約pk_StudentCourse主キーを追加します（StudentId、CourseId）

これは、主キーpk_StudentCourseのために、見て、そして二つのフィールドStudentId CourseIdが含まれています。

外部キーの名前

外部キーがある名前のテーブル_名外部キー参照のfk_外部キーテーブル名。テーブルからの外部キーなので、上記の式のように書くことができるテーブルためプライマリ・テーブルからfk_テーブル_名。

[名前]フィールドには、外部キー、外部キーと全く異なるコンセプトを備えた外部キー・フィールドが含まれています。：外部キーフィールドには、それをすることが推奨され、名前が含まれているテーブル+ Idの外部キー名。

関係テーブルホテル、フィールドID、名前、CityIdを考えてみましょう。表市は、ID、名前をフィールドに入力します。市はホテルの多くを持っているかもしれないので、関係は、多くの1つであるため、市は、メインテーブル（1辺）、リストからホテル（マルチパーティ）です。表中のホテル、CityIdは外部キーとしてあります。

外部キーを実装するとき、私たちは書くことができます。

表HotelInfoは、ALTER
制約fk_HotelInfo_City外部キー（CityID）参考シティ（ID）を追加
、更新には何のアクションをアクションなしを削除しないオン

もちろん、fk_HotelInfo_Cityは外部キーの名前で、CityIdは外部キーの名前は、フィールドが含まれています。

注：データベーステーブルを作成するとき、それは通常、3つの書かれたSQLスクリプトファイルを取ります。最初のファイルは、表計算書を作成し、すべてのテーブルを作成するための唯一のSQLステートメントが含まれています。2番目のファイルがステートメントが含まれており、このドキュメントの後半に集中した文を削除関係は、この文書の上部に集中すなわちドロップ制約文のすべてが、文はすべてのテーブル、DROP TABLE文を削除し、関係表を、削除しますセクション。3番目のファイルは、文はテーブル間の関係を確立含まれています。データベースを移植するとき、私はあなたに一目で試して説明していますので、このアプローチは、より便利になります。

外部キーフィールドについては、多くの関係の解析テーブルが含まれて、KOを押し下げ、我々は書くことができます（学生数の多くの例に多くに戻ります）：

学生解像度テーブルStudentCourseテーブルと外部キー関係を確立します。

表StudentCourseは、ALTER
制約fk_StudentCourse_Student外部キー（StudentId）参照の学生（ID）を追加
で更新アクションなしには何のアクションを削除しません

解決テーブルStudentCourseコース表に外部キー関係を確立します。

アルター表StudentCourseは
制約fk_StudentCourse_Course外部キー（CourseId）参考コース（Id）の追加
アップデートノーアクションの削除なしのアクションを

トリガー名

これは3つの部分から構成されます。

接頭語（TR）は、データベース・オブジェクトのタイプを記述する。
基本部分の表に記載さトリガーが適用されます。
サフィックス（_I、_U、_D）は、（挿入、更新、削除）修正文を示し

ストアドプロシージャの名前

ご存知のように、接頭辞システムストアドプロシージャは、システムストアドプロシージャ、ストアドプロシージャを持つユーザを混乱を避けるために、SP_ですが、私はあなたがPR独自の定義として、ストアドプロシージャの名前を使用することをお勧めします。

一方、命名規則は、次のような自明の名前のタイプ：prGetItemById。

ここでは、検討に値する興味深い場所があります。ストアドプロシージャを命名する際、我々は、上記の規則に従って2つの方法で使用することができます。

動詞の前に置き、戻す名詞。
名詞の前に入れて、動詞を戻します。

私は個人的に、今、私たちは、さまざまな理由についての話、モード2を使用してお勧めします。

prEmployeeInsert、prEmployeeUpdate、prEmployeeDelById、prEmployeeGetById：のNorthwindにたとえば、あなたは、4ストアド・プロシージャのEmployeesテーブルを持っている場合は、次のように命名しました

prProductInsert、prProductUpdate、prProductDelById、prProductGetById：Productsテーブルのためには、と命名された4つの類似したストアドプロシージャを持っていながら、

あなたが表示するEnterprise Managerを使用する場合次に、あなたはこのきちんとした配置のようなストアドプロシージャを見つけます：

prEmployeeDelById
prEmployeeGetById
prEmployeeInsert
prEmployeeUpdate
prProductDelById
prProductGetById
prProductInsert
prProductUpdate

それはあなたのストアドプロシージャは、このアプローチのより多くの明白な利点にちなんで名付けられた長い時間を見つけるのは簡単です。

ストアドプロシージャのパラメータを命名

エントランスパラメータは、ストアドプロシージャを、私は彼らが対応すると同じフィールド名を示唆し、ここで、それは（簡略化を行う）のNorthwindデータベースの従業員テーブルにストアドプロシージャの更新を書き込むことが想定され、あなたが書くことができます。

手順prEmployeeUpdateById作成
    @EmployeeId INT、
    @LastName NVARCHAR（20）、
    @FirstName NVARCHAR（10）
として
    更新従業セット
       氏名= @LastName、
       姓= @FirstName
    場合
       社員= @EmployeeId

    <エラー@@場合> 0又は@ @ROWCOUNT = 0
       RAISERROR 16001 '更新用户失败'

概要

この記事では、私が最初の問題に十分な注意を命名データベースオブジェクトの開発を提案して、データオブジェクトという名前のプロファイルを示しています。

それから私のテーブル、フィールド、主キー、外部キー、トリガ、ストアドプロシージャ順次、規則データベースという名前のオブジェクトの詳細な説明によります。

その間、私はまた、ストアドプロシージャの管理におけるテーブルの建設だけでなく、スキルを取ることができたときに知っておくべき問題を含め、カバーとデータベース開発のいくつかの一般的な問題を散在します。

うまくいけば、この記事はあなたを助ける与えます。

ます。https：//www.cnblogs.com/JimmyZhang/archive/2007/08/30/875504.htmlで再現