誰もがTSQLのコーディング標準を推奨できますか？

私たちには長い間、.Netコードのコーディング標準がありました。それらを適用する方法に関するアイデアについては、時間とともに進化する信頼できるソースがいくつかあるようです。

私たちの製品で使用するために記述されたSQLのいくつかの標準をまとめることができるようにしたいのですが、適切に記述されたSQLを決定するものについてコンセンサスに関するリソースがそこにないようです。

私の経験では、主に次のことを探します。

• テーブルと列の名前付け-IDタイプの列にID、参照、または番号を使用するか、名前に単数形または複数形を使用するかを確認します（複数形はテーブル名に共通-THINGS、列名には単数形-たとえばTHING_ID）。私にとってここで最も重要なことは、人々が時間を無駄にすることを回避する一貫性です（たとえば、テーブル名が単数であることを直感的に知っているため、誰かがTHINGをテーブル名として入力したタイプミスに遭遇しません）。

• すべての作成には、ファイルの一部としてドロップ（存在するオブジェクトを条件とする）を含める必要があります。また、あなたに許可を与えることもできます。

• 選択、更新、挿入、削除は、1つの列名、1つのテーブル名、1つのwhere句/ order by句を1行に1つずつ配置して、デバッグ中に一度に1つずつ簡単にコメント化できるようにする必要があります。

• 特に混乱する可能性のあるオブジェクトタイプのプレフィックス（ビューのvが最も重要です）。それでも適用できるかどうかはわかりませんが、以前はシステムプロシージャ以外のストアドプロシージャがsp_を開始するには非効率でした。とにかく、それらを区別するためのベストプラクティスは、usp_が最近使用したものでした。

• トリガーの名前に、それが更新/挿入/削除用かどうか、および適用されるテーブルを含める方法を示す標準。優先する基準はありませんが、これは重要な情報であり、簡単に見つけられるはずです。

• SQL Serverの以前のバージョンのオブジェクトの所有権に関する基準、または2005年以降に存在するはずのスキーマ。それはあなたの呼び出しですが、何か/それがどこにあるかを誰が所有しているのか、そして可能であればスキーマ/所有者をCREATEスクリプトに含めて、誤って作成される可能性を最小限に抑えることを決して推測しないでください。

• SELECT *を使用している人は誰でも自分の尿を1パイント飲むように指示されます。

• 本当に正当な理由がない限り（これには、ユーザーの怠惰は含まれません）、最初から主キー/外部キーの関係を保持、強制、および維持します。これは、結局のところ、リレーショナルデータベースがフラットファイルではなく、孤立したレコードが、ある時点でサポートライフを地獄にしてしまうからです。また、あなたが今それをしなければ、あなたがデータを取得すると作業の10倍になるので、イベント後にそれを実装することは決してできないと約束できます（これは強制したことがないので少しねじ込まれます）関係）。

私は何かを逃したと確信していますが、私にとってそれらは、かなりの数の状況で実際に本当の利益を提供するものです。

しかし、すべての標準と同様に、少ないほど多くなります。コーディング標準が長いほど、人々がそれらを読んで使用する可能性は低くなります。十分な間隔を置いて配置されたページをいくつか通過したら、実際に実際に変化をもたらさないものをドロップしようとします。これは、ユーザーがそれを実行する可能性を減らすためです。

編集：2つの修正-所有権セクションのスキーマを含め、count（*）に関する誤ったヒントを削除します-以下のコメントを参照してください。

適切に記述されたSQLを決定するものについてのコンセンサスに関して、そこにリソースはないようです

それはコンセンサスがないからです。例として、私はジョンホプキンスのリストの少なくとも半分の項目について異なる答えを持っているでしょう、そして彼のリストの詳細の量に基づいて、私たち2人が生活のためにデータベースで作業していることは安全な推測です。

とは言っても、コーディング標準は依然として適切なものであり、チームの全員が理解して同意する標準の方が優れているため、その標準に準拠する可能性が高くなります。

ジョン・ホプキンスの答えに加えて...

• 内部オブジェクトと外部オブジェクトを分離する

  • 制約、インデックスなどのIX、UQ、TRG、CKなど
  • usfThing_Addなどのクライアント向けの小文字またはCapsCase

• 内部オブジェクトの場合、「デフォルト以外」の場合は明示的にします

  • UQ =一意制約
  • UQC =一意のクラスター化制約
  • PK =主キー
  • PKN =非クラスター化主キー
  • IX =インデックス
  • IXU =一意のインデックス
  • IXC =クラスタ化インデックス
  • IXCUまたはIXUC =一意のクラスター化インデックス

• スキーマを使用して、名前と権限を簡素化します。例：

  • 内部プロシージャのHelper.xxx
  • udfsのHelperFn.xxx
  • 直面しているコードのWebGUI.xxx
  • テーブルのデータおよび/または履歴および/またはステージング