t-sqlのストアドプロシージャに名前を付けるベストプラクティスは何ですか？

Question

私はいくつかの大きなデータベースで働いているし、ストアドプロシージャの名前が非常に異なっていた：

SP_PrefixXXX 
PrefixYyyXxx 
Prefix: Rep, Act 

命名のベストプラクティスは何ですか？どのように適切な方法でそれらを整理できますか？

Answer 1

最高の命名規則は、データベース全体で一貫性のあるものである:)

は本当に、それはあなたとあなたのチーム次第です。それが明確かつ賢明である限り、かなりの余裕があります。あなたが決めたものは誰でもそれを守るようにしてください。大会自体よりもはるかに重要なことは、誰もがそれに固執するということです。

私はsp_とusp_などを避ける傾向があります。なぜなら、私はそれらが冗長であると判断するからです。例えば、InsertCustomerと呼ばれるsprocは明らかにsprocであり、決してテーブル、ビュー、または他の種類のオブジェクトと混同することはありません。特にsp_は避けなければならない。

私はCamelCaseが好きですが、これも好みの問題です。私はprocが何の良い指標を与えるために私のprocの名前が好き - 例えば：

InsertSalesOrder PopulateItemStagingTables CalculateOrderSummary PrepareCustomerStatements

など

Answer 2

まあ、 "SP_" と名前を前置されますかなり冗長です。実装の名前です（テーブルやビューではなくSPです）。それが実装されていることを伝える多くの他の方法（システム、情報スキーマ、使用方法）があります。

代わりに、インターフェイスの名前を指定する必要があります。便宜上（多くのものがアルファベット順に並べ替えられているので）、同じ名前の下に、同じプレフィックスを使用して同様のものをグループ化するのが好きです。

また、の名前ではなく、の実装方法についても説明します。

一般に、データベースオブジェクトの一般的な命名規則では、CamelCaseの代わりにアンダースコアを使用しています。これは大会の問題です。単なる慣例ではないのは、データベースオブジェクトのすべての小文字を使用する共通の規約です。これにより、大文字小文字を区別しない場合とそうでない場合があるサーバー設定を無視することができます。

Answer 3

"sp_"でも "usp_"でもありません。我々はを知っている彼らはストアドプロシージャ、命名計画は私たちに教える必要はありません。

私は一般に、彼らが何をしているのかという名前をつけて、おそらくスキーマでそれらを分割します。ただし、「通常の」データベース操作の一部として直接使用されるのではなく、SSISパッケージがデータベースを参照するために使用するストアドプロシージャには、「ssis_」接頭辞を使用する点を除きます。関数を示すために "fn_"を使用して、ストアドプロシージャと区別することができます。

Answer 4

私は、その機能が何であるかというアイデアを与えるだけでなく、入力変数が何であるかという名前を与える傾向があります。例えば

： ProcessMathEquationWithFieldIdPlantId

これは、それを使用して他の人にすぐに情報を提供するのに役立ちます、私は信じています。

名前の衝突の可能性を制限するためにsp_とusp_も使用しないでください。

Answer 5

接頭辞はシステムプロシージャーの略で、ではなく、を通常の手順の接頭辞として使用する必要があります。これを行うと、プロシージャを探すたびにmasterデータベースへの余分なトリップが行われ、プロシージャの名前と同じ名前が付いていれば、プロシージャの代わりにそのプロシージャが実行されます。

それ以外の名前付け規則は自由に設定できます。当社が使用するものはsubsystem_object_actionです。 main_Customer_Get。これは、一緒に属している手続きを相互に近づけることになります。

Answer 6

私はそれらに接頭辞を付けて、特定のオブジェクトを扱うSPが一緒にグループ化されるようにします。ので、代わりのようなもの：

 
    InsertUser 
    UpdateUser 
    DeleteUser 
    GetUsers 

私はこのようにそれを行う：

 
    AppName_User_GetUser 
    AppName_User_InsertUser 
    AppName_User_UpdateUser 
    AppName_User_DeleteUser 

私はこれは私があまりにも私のSQL管理アプリで、私のコードで管理するのが簡単です見つけます。他の人々と同様に

は本当にこの場合の具体的な「ベストプラクティス」があれば、私は知らないSP_

Answer 7

接頭辞はありません、と述べました。私が現在いる会社では、標準はusp [ProcedureName]（アンダースコアなし）です。私は個人的に接頭辞を全く好みませんが、あなたが会社やプロジェクトに新規参入し、既存の基準を持っている場合、sp_を使用しない限り、これを使用しない技術的理由がある場合は、おそらく私は確かにそれはすべての場合は、大規模な基準ではないと思うので、議論の価値がある問題です。

一般的に名前を変更する慣習は、あなたが議論を持ち、他のチームメンバーがあなたに同意せず、コンセンサスの基準が異なる場合、すぐにそれを放棄してコンセンサスを受け入れることです。一般的には、他のチームメンバーとうまくやって「難しい」という評判を上げていないように、一貫性は実際の標準よりも重要です。

Answer 8

イムないプロが、私はこの方法でアプリケーション= XYの

プレフィックスが好きです。ビュー= v;ストアドプロシージャ= p;関数= f

Table: XY_Name 
View: vXY_Name 
Procedure: sXY_Name 
Function: fXY_Name 

あなたはどう思いますか？私はいくつかの人々がオブジェクトの種類を識別するために2つの文字を使用するが、1つの文字はほとんどの場合、右ですか？

Answer 9

別個のモジュール用にスキーマを作成する方がよい。

次に、意味のある単純な名前を付けます。

例：学校のプロジェクトを行っている場合。

学生スキーマ

プロシージャ名を作成：このAddStudent

だから、先生モジュールのStudent.AddStudent

procedurelistで同じもののようになります。

Answer 10

をします助けて。私は、フロント/バックエンドプログラマだとして、私は、MySQLとSQLServerの両方のために、以下を使用します。

SPx_PAGE/MODULE_ACTION_OBJECT 

X：インデックスが存在していない場合は、読み取りのためのRは、挿入のためのI、U、更新、書き込みのためのW（コンバインのために挿入したり、存在する場合は更新）、削除の場合はDを入力します。

/モジュールのページ：

例プロシージャを呼び出す場所：

SPR_DASHBOARD_GET_USERS //reads users data 
SPW_COMPANIES_PUT_COMPANY //creates or modifies a company