ストアドプロシージャの命名規則は何ですか？[閉まっている]

ストアドプロシージャの命名に関するさまざまなルールを見てきました。

sproc名の前にusp_を付ける人もいれば、アプリ名の省略形を付ける人もいれば、所有者名を付ける人もいます。本当に意味がない限り、SQL Serverでsp_を使用しないでください。

プロシージャ名を動詞で始める人もいます（Get、Add、Save、Remove）。その他はエンティティ名を強調します。

何百ものsprocが存在するデータベースでは、すでに存在すると思われる場合、スクロールして適切なsprocを見つけるのは非常に困難です。命名規則により、sprocを見つけやすくなります。

命名規則を使用していますか？それを説明し、他の選択肢よりも好む理由を説明してください。

返信の概要：

• 誰もがネーミングの一貫性を主張しているようですが、誰にとっても同じネーミング規則を使用する方が、特定のネーミング規則を使用するよりも重要かもしれません。
• 接頭辞：多くの人がusp_または類似のもの（ただしまれにsp_）を使用していますが、他の多くはデータベースまたはアプリ名を使用しています。賢いDBAの1人は、gen、rpt、およびtskを使用して、一般的なCRUD sprocを、レポートまたはタスクに使用されるものと区別します。
• 動詞+名詞は名詞+動詞よりわずかに人気があるようです。動詞にSQLキーワード（選択、挿入、更新、削除）を使用する人もいれば、GetやAddなどのSQL以外の動詞（またはそれらの省略形）を使用する人もいます。単一名詞と複数名詞を区別して、1つまたは複数のレコードが取得されているかどうかを示すものもあります。
• 必要に応じて、最後に追加のフレーズが提案されます。GetCustomerById、GetCustomerBySaleDate。
• 名前のセグメント間にアンダースコアを使用する人もいれば、アンダースコアを使用しない人もいます。app_ Get_CustomerとappGetCustomerの比較-読みやすさの問題だと思います。
• sprocの大規模なコレクションは、OracleパッケージまたはManagement Studio（SQL Server）ソリューションとプロジェクト、またはSQL Serverスキーマに分離できます。
• 不可解な略語は避けてください。

私が選んだ答えを選ぶ理由：良い回答がたくさんあります。皆さん、ありがとうございました！ご覧のとおり、1つだけを選択するのは非常に困難です。私が選んだものは私に共鳴しました。私は彼が説明するのと同じ道をたどりました-動詞+名詞を使用しようとすると、顧客に適用されるすべてのsprocを見つけることができません。

既存のsprocを見つけたり、存在するかどうかを判断したりできることは非常に重要です。誰かがうっかり別の名前で重複したsprocを作成すると、深刻な問題が発生する可能性があります。

私は通常、何百ものsprocを持つ非常に大規模なアプリを扱っているので、最も見つけやすい命名方法を好みます。小さいアプリの場合は、メソッド名の一般的なコーディング規則に従っているため、動詞+名詞を推奨します。

彼は、あまり役に立たないusp_ではなく、アプリ名をプレフィックスとして付けることも推奨しています。複数の人が指摘したように、データベースには複数のアプリのsprocが含まれている場合があります。したがって、アプリ名を前に付けると、sprocを分離するのに役立ち、DBAや他の人がsprocがどのアプリに使用されているかを判別するのに役立ちます。

私の最後のプロジェクトでは、usp_ [Action] [Object] [Process]を使用したため、たとえば、usp_AddProductまたはusp_GetProductList、usp_GetProductDetailを使用しました。ただし、データベースは700プロシージャ以上になり、特定のオブジェクトのすべてのプロシージャを見つけることは非常に困難になっています。たとえば、製品の追加には50の奇数の追加手順を、取得などには50の奇数を検索する必要があります。

このため、新しいアプリケーションでは、プロシージャ名をオブジェクトごとにグループ化することを計画しています。また、いくらか冗長であると感じたため、uspを削除しています。手順自体。

新しい形式は次のとおりです

[App]_[Object]_[Action][Process]

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

特に大量のsprocがある場合は、後で簡単に見つけられるようにグループ化するのに役立ちます。

複数のオブジェクトが使用されている場合、ほとんどのインスタンスにはプライマリオブジェクトとセカンダリオブジェクトがあるため、プライマリオブジェクトは通常のインスタンスで使用され、セカンダリはApp_Product_AddAttributeなどのプロセスセクションで参照されます。

ここでは、SQL Serverのsp_プレフィックスの問題について説明します。

接頭辞sp_が付いた名前のストアドプロシージャは、Masterデータベースに格納されているシステムsprocです。

sprocにこのプレフィックスを付けると、SQL ServerはまずMasterデータベースでそれらを検索し、次にコンテキストデータベースで検索するため、不必要にリソースを浪費します。また、ユーザーが作成したsprocがシステムのsprocと同じ名前の場合、ユーザーが作成したsprocは実行されません。

接頭辞sp_は、sprocがすべてのデータベースからアクセス可能であることを示しますが、現在のデータベースのコンテキストで実行する必要があることを示します。

ここだパフォーマンスヒットのデモが含まれて素敵な説明は、。

これは、コメントでAntが提供する別の役立つソースです。

システムハンガリー語（上記の「usp」接頭辞のように）に震えます

構造の異なるさまざまなデータベース間で多くのストアドプロシージャを共有しているため、データベース固有のデータベースでは、データベース名自体のプレフィックスを使用します。共有プロシージャにはプレフィックスがありません。このようなやや醜い接頭辞を完全に取り除くには、別のスキーマを使用することが代替策になると思います。

接頭辞の後の実際の名前は、関数の命名とほとんど変わりません。通常、「追加」、「設定」、「生成」、「計算」、「削除」などの動詞と、それに続く「ユーザー」などのより具体的な名詞"、" DailyRevenues "などのようになります。

Antのコメントへの応答：

1. テーブルとビューの違いは、その内容にアクセスしたり変更したりする人ではなく、データベーススキーマを設計する人に関係します。スキーマの詳細が必要になるというまれなケースでは、見つけるのは簡単です。カジュアルなSELECTクエリの場合は関係ありません。実際、テーブルとビューを同じように扱えることは大きな利点だと思います。
2. 関数やストアドプロシージャとは異なり、テーブルまたはビューの名前が動詞で始まることや、1つ以上の名詞以外の名前になることはほとんどありません。
3. 関数では、スキーマプレフィックスを呼び出す必要があります。実際、呼び出し構文（とにかく使用する）は、関数とストアドプロシージャで大きく異なります。しかし、そうでなかったとしても、1と同じです。関数とストアドプロシージャを同じように扱うことができるのに、なぜ私はそうしないのですか？

私は長年にわたってさまざまなシステムのほとんどすべてを使用してきました。私はようやくこれを開発し、今日も使い続けています：

接頭辞：

• gen-一般：CRUD、ほとんど
• rpt-レポート：説明不要
• tsk-タスク：通常は手続き型ロジックを備えたもので、スケジュールされたジョブを介して実行されます

アクション指定子：

Ins - INSERT
Sel - SELECT
Upd - UPDATE
Del - DELETE

（プロシージャが多くのことを行う場合、全体的な目標はアクション指定子を選択するために使用されます。たとえば、顧客のINSERTはかなりの準備作業を必要とするかもしれませんが、全体的な目標はINSERTなので、「Ins」が選択されます。

オブジェクト：

gen（CRUD）の場合、これは影響を受けるテーブルまたはビューの名前です。rpt（レポート）の場合、これはレポートの簡単な説明です。tsk（タスク）の場合、これはタスクの短い説明です。

オプションのクラリファイア：

これらは、手順の理解を深めるために使用されるオプションの情報ビットです。例としては、「By」、「For」などがあります。

フォーマット：

[プレフィックス] [アクション指定子] [エンティティ] [オプションのクラリファイア]

プロシージャ名の例：

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

TableName_WhatItDoes

• Comment_GetByID

• 顧客リスト

• UserPreference_DeleteByUserID

接頭辞や愚かなハンガリー語のナンセンスはありません。最も密接に関連付けられているテーブルの名前と、その機能の簡単な説明。

上記の注意点の1つは、自動生成されたすべてのCRUDに常にzCRUD_をプレフィックスとして付けることで、リストの最後に移動して、見なくても済むようにすることです。

sp_SQL Serverでは、システムsprocがすべてsp_で始まるため、ストアドプロシージャ名をで開始することはできません。一貫した名前付け（hobgoblin-domの範囲でさえ）は、データディクショナリに基づく自動化されたタスクを容易にするので便利です。プレフィックスはスキーマをサポートするため、SQL Server 2005ではプレフィックスの有用性が少し低くなります。スキーマはさまざまな種類の名前空間に使用でき、名前のプレフィックスと同じように使用できます。たとえば、スター・スキーマに、一つは持っている可能性が薄暗いと事実スキーマをし、この規則によって表を参照してください。

ストアドプロシージャの場合、プレフィックスは、システムsprocからアプリケーションsprocを識別するために役立ちます。 up_対は、sp_データ・ディクショナリから非システムストアドプロシージャを識別することが比較的容易になります。

私は常にストアドプロシージャをパッケージにカプセル化します（私は職場でOracleを使用しています）。これにより、個別のオブジェクトの数が減り、コードの再利用に役立ちます。

命名規則は好みの問題であり、プロジェクトの開始時に他のすべての開発者と同意する必要があります。

小さなデータベースでは、uspTableNameOperationNameを使用します（例：uspCustomerCreate、uspCustomerDeleteなど）。これにより、「メイン」エンティティによるグループ化が容易になります。

大規模なデータベースの場合、スキーマまたはサブシステム名（Receiving、Purchasingなど）を追加して、それらをグループ化します（SQLサーバーはそれらをアルファベット順に表示するため）

わかりやすくするために、名前の省略形は避けます（プロジェクトの新しい人は、sprocの名前がuspUsingNoAbbreviationsIncreasesClarityForEveryoneであるため、「UNAICFE」が何を意味するのか不思議に思う必要はありません）。

私は現在、次のような形式を使用しています

表記：

[プレフィックス] [アプリケーション] [モジュール] _ [名前]

例：

P_CMS_USER_UserInfoGet

私はいくつかの理由でこの表記が好きです：

• 非常に単純なプレフィックスで開始すると、プレフィックスで始まるオブジェクトのみを実行するようにコードを記述できます（SQLインジェクションを減らすためなど）。
• 私たちのより大きな環境では、複数のチームが同じデータベースアーキテクチャで実行される異なるアプリで作業しています。アプリケーション表記は、SPを所有するグループを指定します。
• モジュールと名前のセクションは単に階層を完成させます。すべての名前は、階層からのグループ/アプリ、モジュール、関数に一致する必要があります。

私は常に使用します：

usp [テーブル名] [アクション] [詳細]

「tblUser」というテーブルがあるとすると、次のようになります。

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

手順はテーブル名と機能によってアルファベット順に並べ替えられているので、特定のテーブルに対して何ができるかを簡単に確認できます。接頭辞「usp」を使用すると、他のプロシージャ、複数のテーブル、関数、ビュー、サーバーとやり取りする1000行のプロシージャを（たとえば）作成している場合、何を呼び出しているかを知ることができます。

SQL Server IDEのエディターがVisual Studioと同じになるまで、プレフィックスを保持します。

application prefix_ operation prefix_関係するデータベースオブジェクトの説明（アンダースコア間のスペースを除く-表示するにはスペースを入れる必要がありました）。

使用する操作接頭辞-

• “ 取得」–レコードセットを返します
• 「ins」–データを挿入します
• 「upd」–データを更新します
• 「del」–データを削除します

例えば

wmt_ ins _ customer _details

「従業員管理ツール、詳細を顧客テーブルに挿入」

利点

同じアプリケーションに関連するすべてのストアドプロシージャは、名前でグループ化されています。グループ内では、同じ種類の操作（挿入、更新など）を実行するストアドプロシージャがグループ化されます。

このシステムは私たちにとってはうまく機能します。1000のストアドプロシージャが1つのデータベースにあります。

これまでのところ、このアプローチに不利な点はありません。

GetXXX-@IDに基づいてXXXを取得します

GetAllXXX-すべてのXXXを取得します

PutXXX-@IDが-1を渡された場合、XXXを挿入します。他の更新

DelXXX-@IDに基づいてXXXを削除します

usp_命名規則は誰にとっても役に立ちません。

以前はCRUD操作にGet / Update / Insert / Deleteプレフィックスを使用していましたが、今ではLinq to SQLまたはEFを使用してCRUD作業のほとんどを行っているため、これらは完全になくなりました。新しいアプリケーションにはストアドプロシージャがほとんどないため、以前のように命名規則は問題になりません;-)

現在取り組んでいるアプリケーションについては、アプリケーション名を識別するプレフィックス（4つの小文字）があります。これは、アプリケーションが同じデータベース内のレガシーアプリケーションと共存できる必要があるためです。そのため、プレフィックスは必須です。

レガシー制約がなかった場合は、プレフィックスを使用しないと確信しています。

接頭辞の後は、通常、SP名の先頭に、プロシージャの動作を説明する動詞と、操作するエンティティの名前を記述します。エンティティ名の複数化は許可されます-読みやすさを強調するため、名前だけからプロシージャが何を行うかが明確になります。

私たちのチームの典型的なストアドプロシージャ名は次のようになります。

shopGetCategories
shopUpdateItem

論理的で一貫性がある限り、プレフィックスが何であるかは重要ではないと私は思います。個人的に使用

spu_ [アクションの説明] [プロセスの説明]

ここで、アクションの説明は、取得、設定、アーカイブ、挿入、削除などの典型的なアクションの小さな範囲の1つです。プロセスの説明は、短いが説明的なものです。たとえば、

spu_archiveCollectionData 

または

spu_setAwardStatus

関数にも同様の名前を付けますが、接頭辞にudf_を付けます

プロシージャの命名に疑似ハンガリー記法を使用しようとする人を見たことがありますが、私の意見ではそれが明らかにする以上に隠されています。手順をアルファベット順にリストしている限り、機能別にグループ化されているのがわかりますが、これは順序と不要な厳密さの間のスイートスポットのようです。

SQlサーバーでsp_ *を使用しないでください。システムに保存されているすべてのプロシージャがsp_で始まるため、システムが名前に対応するオブジェクトを見つけるのが難しくなります。

したがって、sp_以外の何かから始めると、物事が簡単になります。

そのため、最初にProc_の一般的な名前を使用します。これにより、1つの大きなスキーマファイルが存在する場合に、手順を簡単に識別できます。

それとは別に、関数を識別する接頭辞を割り当てます。お気に入り

Proc_Poll_Interface, Proc_Inv_Interface 等

これにより、POLLとInventoryを実行するすべてのストアドプロシージャを見つけることができます。

とにかく、プレフィックスシステムは問題のドメインによって異なります。しかし、Alは、人々が編集のためにExplorerドロップダウンでストアドプロシージャをすばやく見つけられるようにするためであっても、同様の何かが存在するはずであると述べ、実行しました。

他のegの機能。

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

関数ベースの命名coz Procsは、テーブルのような静的オブジェクトではなく、コード/関数に似ています。Procsが複数のテーブルで機能する可能性があることは役に立ちません。

プロシージャが単一の名前で処理できるよりも多くの機能を実行した場合、それは、プロシージャが必要以上に多くの機能を実行していて、それらを再度分割する時間であることを意味します。

お役に立てば幸いです。

スレッドの後半に参加しましたが、ここに返信を入力します。

私の最後の2つのプロジェクトでは、次のような異なる傾向があります。

データを取得するには：s <tablename> _G
データを削除するには：s <tablename> _D
データを挿入するには：s <tablename> _I
データを更新するには：s <tablename> _U

この命名規則は、フロントエンドで単語dtを前に付けることによっても従います。

例：

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

アプリケーションでの上記の命名規則の助けを借りて、私たちは良い覚えやすい名前を持っています。

2番目のプロジェクトでは、illが異なる同じ命名規則を使用しました。

データを取得するには：sp_ <tablename> G
データを削除するには：sp_ <tablename> D
データを挿入するには：sp_ <tablename> I
データを更新するには：sp_ <tablename> U

例：

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU