ストアドプロシージャの命名規則は何ですか? [閉まっている]
-
04-07-2019 - |
質問
ストアドプロシージャの命名に関するさまざまなルールを見てきました。
sproc名の前にusp_を付ける人もいれば、アプリ名の略語を付ける人もいれば、所有者名を付けた人もいます。本当に意味するのでない限り、SQL Serverでsp_を使用しないでください。
動詞(Get、Add、Save、Remove)でproc名を開始するものもあります。その他はエンティティ名を強調します。
何百ものsprocがあるデータベースでは、既に存在すると思われる場合にスクロールして適切なsprocを見つけるのは非常に困難です。命名規則により、Sprocを簡単に見つけることができます。
命名規則を使用していますか?それを説明し、他の選択肢よりもそれを好む理由を説明してください。
返信の概要:
- 誰もが命名の一貫性を主張しているようです。誰もが特定の命名規則よりも同じ命名規則を使用することがより重要である可能性があります。
- プレフィックス:多くの人がusp_または類似の(ただしsp_はめったにありません)を使用していますが、他の多くの人はデータベース名またはアプリ名を使用しています。賢いDBAの1人は、gen、rpt、およびtskを使用して、一般的なCRUD sprocをレポートやタスクに使用されるものと区別します。
- 動詞+名詞は、名詞+動詞よりも若干人気があるようです。動詞にSQLキーワード(Select、Insert、Update、Delete)を使用する人もいれば、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がコメント。
Systems Hungarian (上記の<!> quot; usp <!> quotのような; prefix)私は身震いします。
類似の構造を持つさまざまなデータベース間で多くのストアドプロシージャを共有するため、データベース固有のデータベースでは、データベース名自体のプレフィックスを使用します。共有プロシージャにはプレフィックスがありません。さまざまなスキーマを使用することは、このようなややugいプレフィックスを完全に取り除くための代替手段になると思います。
プレフィックスの後の実際の名前は、関数の命名とほとんど変わりません。通常、<!> quot; Add <!> quot;、<!> quot; Set <!> quot;、<!> quot; Generateのような動詞です。 <!> quot;、<!> quot; Calculate <!> quot;、<!> quot; Delete <!> quot;など、その後に<!> quot; User <!>などの特定の名詞がいくつか続きますquot;、<!> quot; DailyRevenues <!> quot;など。
Antのコメントへの応答:
- テーブルとビューの違いは、データベーススキーマを設計する人に関係し、その内容にアクセスまたは変更する人には関係ありません。まれにスキーマの詳細が必要な場合、見つけるのは簡単です。カジュアルなSELECTクエリの場合、それは無関係です。実際、テーブルとビューを同じように扱うことができるのは大きな利点だと思います。
- 関数やストアドプロシージャとは異なり、テーブルやビューの名前は動詞で始まることはほとんどありません。また、1つ以上の名詞以外の名前でもありません。
- 関数を呼び出すには、スキーマプレフィックスが必要です。実際、呼び出し構文(とにかく使用する)は、関数とストアドプロシージャで大きく異なります。しかし、そうでなくても、1と同じことが当てはまります。関数とストアドプロシージャを同じように扱うことができるのなら、なぜ私はすべきではないのでしょうか。
ストアドプロシージャ名をsp_
で開始すると、システムsprocはすべてsp_で始まるため、SQL Serverでは不適切です。一貫した命名(hobgoblin-domの範囲まで)は、データディクショナリに基づいて自動化されたタスクを容易にするため便利です。 SQL Server 2005では、スキーマがサポートされているため、プレフィックスの有用性がやや劣ります。スキーマは、名前のプレフィックスが使用される方法でさまざまな種類の名前空間に使用できます。たとえば、スタースキーマでは、 dim および fact スキーマを使用して、この規則で表を参照できます。
ストアドプロシージャの場合、アプリケーションsprocをシステムsprocから識別するためにプレフィックスを使用すると便利です。 up_
vs. <=>を使用すると、データディクショナリから非システムストアドプロシージャを比較的簡単に識別できます。
TableName_WhatItDoes
-
Comment_GetByID
-
Customer_List
-
UserPreference_DeleteByUserID
接頭辞なし、または愚かなハンガリーのナンセンス。最も密接に関連付けられているテーブルの名前と、その機能の簡単な説明。
上記の注意点:個人的には、自動生成されたすべてのCRUDの先頭にzCRUD_を付けることで、リストの最後でソートする必要がないようにします。
私は長年にわたってほとんどすべての異なるシステムを使用してきました。私はついにこれを開発し、今日も使用し続けています:
プレフィックス:
- gen-一般:CRUD、主に
- rpt-レポート:説明不要
- tsk-タスク:通常、スケジュールされたジョブを介して実行される手続きロジックを備えたもの
アクション指定子:
Ins - INSERT
Sel - SELECT
Upd - UPDATE
Del - DELETE
(プロシージャが多くのことを行う場合、全体的な目標はアクション指定子を選択するために使用されます。たとえば、顧客のINSERTはかなりの準備作業を必要としますが、全体的な目標はINSERTなので、<!> quot; Ins <!> quot;が選択されています。
オブジェクト:
gen(CRUD)の場合、これは影響を受けるテーブルまたはビューの名前です。 rpt(レポート)の場合、これはレポートの短い説明です。 tsk(タスク)の場合、これはタスクの簡単な説明です。
オプションのクラリファイヤー:
これらは、手順の理解を深めるために使用されるオプションの情報です。例には、<!> quot; By <!> quot;、<!> quot; For <!> quot;などが含まれます。
形式:
[プレフィックス] [アクション指定子] [エンティティ] [オプションのクラリファイヤー]
プロシージャ名の例:
genInsOrderHeader
genSelCustomerByCustomerID
genSelCustomersBySaleDate
genUpdCommentText
genDelOrderDetailLine
rptSelCustomersByState
rptSelPaymentsByYear
tskQueueAccountsForCollection
常にパッケージにストアドプロシージャをカプセル化します(職場でOracleを使用しています)。これにより、個別のオブジェクトの数が減り、コードの再利用が容易になります。
命名規則は好みの問題であり、プロジェクトの開始時に他のすべての開発者と同意する必要があります。
小さなデータベースの場合、uspTableNameOperationNameを使用します。 uspCustomerCreate、uspCustomerDeleteなど。これにより、「メイン」エンティティによるグループ化が容易になります。
より大きなデータベースの場合、スキーマまたはサブシステム名を追加します。グループ化を維持するための受信、購入など(SQLサーバーはアルファベット順に表示するのが好きなので)
iわかりやすくするために、名前の略語を避けるようにします(プロジェクトの新しい人は、sprocの名前がuspUsingNoAbbreviationsIncreasesClarityForEveryoneであるため、「UNAICFE」が何を表しているのかを気にする必要はありません)
現在、次のような形式を使用しています
表記法:
[PREFIX] [アプリケーション] [モジュール] _ [名前]
例:
P_CMS_USER_UserInfoGet
この表記はいくつかの理由で好きです:
- 非常に単純なPrefixで開始すると、(たとえばSQLインジェクションを減らすために)プレフィックスで始まるオブジェクトのみを実行するようにコードを記述できます
- 大規模な環境では、複数のチームが同じデータベースアーキテクチャを実行する異なるアプリで作業しています。アプリケーション表記は、SPを所有するグループを指定します。
- 「モジュール」セクションと「名前」セクションは、単純に階層を完成させます。すべての名前は、階層からグループ/アプリ、モジュール、機能に一致できる必要があります。
常に使用:
usp [テーブル名] [アクション] [追加の詳細]
<!> quot; tblUser <!> quot;というテーブルを指定すると、次のようになります。
- uspUserCreate
- uspUserSelect
- uspUserSelectByNetworkID
プロシージャは、テーブル名および機能ごとにアルファベット順にソートされているため、特定のテーブルに対してできることは簡単にわかります。プレフィックス<!> quot; usp <!> quot;を使用します。 (たとえば)他のプロシージャ、複数のテーブル、関数、ビュー、およびサーバーとやり取りする1000行のプロシージャを作成している場合に、何を呼び出しているかを知らせます。
SQL Server IDEのエディターがVisual Studioと同等になるまで、プレフィックスを保持します。
application prefix_ operation prefix_関係するデータベースオブジェクトの説明(アンダースコア間のスペースを除く-表示するにはスペースを入れる必要がありました)。
使用する操作プレフィックス-
- <!>#8220; get <!>#8221; <!>#8211;レコードセットを返します
- <!>#8220; ins <!>#8221; <!>#8211;データを挿入します
- <!>#8220; upd <!>#8221; <!>#8211;データを更新します
- <!>#8220; del <!>#8221; <!>#8211;データを削除します
e.g
wmt_ ins _ customer _details
<!> quot;従業員管理ツール、顧客テーブルに詳細を挿入<!> quot;
利点
同じアプリケーションに関連するすべてのストアドプロシージャは、名前でグループ化されます。グループ内では、同じ種類の操作(挿入、更新など)を実行するストアドプロシージャがグループ化されます。
このシステムは、約1つのデータベースに1000個のストアドプロシージャがあります。
これまでのところ、このアプローチの欠点はありません。
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_ [アクションの説明] [プロセスの説明]
ここで、アクションの説明は、get、set、archive、insert、deleteなどの典型的なアクションの小さな範囲の1つです。プロセスの説明は、たとえば短いですが説明的なものです
spu_archiveCollectionData
または
spu_setAwardStatus
同様に関数に名前を付けますが、接頭辞udf _
プロシージャの命名に疑似ハンガリー表記を使用しようとする人々を見てきましたが、私の意見では、それが明らかにする以上のものを隠しています。アルファベット順に手順をリストしている限り、機能ごとにグループ化された手順を見ることができます。それは、私にとって、順序と不必要な厳密さの間のスイートスポットのようです
SQlサーバーでsp_ *を使用しないでください。システムに保存されているすべての手順はsp_で始まるため、システムは名前に対応するオブジェクトを見つけるのが難しくなります。
そのため、sp_以外のものから始めると簡単になります。
したがって、Proc_の一般的な命名を使用して始めます。これにより、1つの大きなスキーマファイルが提供されている場合、プロシージャを簡単に識別できます。
それとは別に、関数を識別するプレフィックスを割り当てます。
Proc_Poll_Interface, Proc_Inv_Interface
など。
これにより、POLLのジョブを実行するすべてのストアドプロシージャと、インベントリなどを実行するすべてのストアドプロシージャを見つけることができます。
とにかくプレフィックスシステムは問題のドメインに依存します。しかし、アルは、人々が編集のためにexplorerドロップダウンのストアドプロシージャを簡単に見つけられるようにするだけであっても、同様の何かが存在するはずだと言って、しました。
その他の機能の例。
Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History
関数ベースの命名cosに従いました。Procsは、テーブルのような静的オブジェクトではなく、コード/関数に似ています。 Procsが複数のテーブルで動作する可能性はありません。
プロシージャが単一の名前で処理できる以上の機能を実行した場合、プロシージャが必要以上に多くの機能を実行しており、それらを再度分割する時間が必要であることを意味します。
役立つこと。
スレッドの後半に参加しましたが、ここに返信を入力します:
最近の2つのプロジェクトでは、次のようなさまざまな傾向があります。
データを取得するには:s <!> lt; tablename <!> gt; _G
データを削除するには:s <!> lt; tablename <!> gt; _D
データを挿入するには:s <!> lt; tablename <!> gt; _I
データを更新するには:s <!> lt; tablename <!> gt; _U
この命名規則は、フロントエンドでも dt という語の接頭辞が続きます。
例:
exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U
アプリケーションの上記の命名規則の助けを借りて、優れた覚えやすい名前があります。
2番目のプロジェクトでは、同じ命名規則を使用しましたが、lilは異なります。
データを取得するには:sp _ <!> lt; tablename <!> gt; G
データを削除するには:sp _ <!> lt; tablename <!> gt; D
データを挿入するには:sp _ <!> lt; tablename <!> gt; I
データを更新するには:sp _ <!> lt; tablename <!> gt; U
例:
exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU