128

ストアドプロシージャに名前を付けるためのさまざまなルールを見てきました。

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

proc名を動詞(Get、Add、Save、Remove)で始めるものもあります。他の人はエンティティ名を強調します。

数百のsprocがあるデータベースでは、すでに存在していると思われる場合、スクロールして適切なsprocを見つけるのは非常に難しい場合があります。命名規則により、sprocの検索が容易になります。

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

返信の概要:

  • 誰もが命名の一貫性を主張しているようです。つまり、どの特定の命名規則を使用するよりも、すべての人が同じ命名規則を使用することがより重要である可能性があります。
  • プレフィックス:多くの人がusp_または同様のもの(ただし、まれにsp_)を使用しますが、他の多くの人はデータベースまたはアプリ名を使用します。賢いDBAの1つは、gen、rpt、tskを使用して、一般的なCRUDsprocをレポートやタスクに使用されるものと区別しています。
  • 動詞+名詞は、名詞+動詞よりも少し人気があるようです。動詞にSQLキーワード(Select、Insert、Update、Delete)を使用する人もいれば、GetやAddなどの非SQL動詞(またはその省略形)を使用する人もいます。1つまたは複数のレコードが取得されているかどうかを示すために、単数形と複数形の名詞を区別するものもあります。
  • 必要に応じて、最後に追加のフレーズが提案されます。GetCustomerById、GetCustomerBySaleDate。
  • 名前セグメントの間にアンダースコアを使用する人もいれば、アンダースコアを避ける人もいます。app_Get_CustomerとappGetCustomer-読みやすさの問題だと思います。
  • sprocの大規模なコレクションは、OracleパッケージまたはManagement Studio(SQL Server)ソリューションとプロジェクト、またはSQLServerスキーマに分離できます。
  • 不可解な略語は避ける必要があります。

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

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

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

彼はまた、あまり役に立たないusp_の代わりにアプリ名を接頭辞として付けることを提唱しています。何人かの人が指摘したように、データベースに複数のアプリのsprocが含まれている場合があります。したがって、アプリ名をプレフィックスとして付けると、sprocを分離し、DBAなどがsprocを使用するアプリを判別するのに役立ちます。

4

17 に答える 17

68

前回のプロジェクトでは、usp_[Action][Object][Process] を使用しました。たとえば、usp_AddProduct または usp_GetProductList、usp_GetProductDetail です。しかし現在、データベースには 700 以上のプロシージャがあり、特定のオブジェクトのすべてのプロシージャを見つけることは非常に困難になっています。たとえば、Product add の場合は 50 個の奇数の Add プロシージャを検索し、Get の場合は 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 など)。

于 2008-10-26T17:50:56.577 に答える
37

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

プレフィックス sp_ で名前が付けられたストアド プロシージャは、Master データベースに格納されているシステム sproc です。

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

sp_ プレフィックスは、すべてのデータベースから sproc にアクセスできるが、現在のデータベースのコンテキストで実行する必要があることを示します。

これは、パフォーマンスヒットのデモを含む素晴らしい説明です。

Ant がコメントで提供している別の役立つ情報源を次に示します。

于 2008-10-26T18:19:05.707 に答える
16

システム ハンガリー語(上記の "usp" プレフィックスのような) には身震いします。

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

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

Ant のコメントへの対応:

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

TableName_WhatItDoes

  • Comment_GetByID

  • 顧客リスト

  • UserPreference_DeleteByUserID

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

上記の 1 つの注意点: 私は常に、自動生成されたすべての CRUD の前に zCRUD_ を付けて、リストの最後に並べ替えて、見る必要がないようにしています。

于 2008-10-26T23:48:54.090 に答える
10

sp_システム sprocs はすべて sp_ で始まるため、ストアド プロシージャ名をSQL Server で開始することは不適切です。データ ディクショナリに基づいて自動化されたタスクを容易にするため、一貫した名前付け (hobgoblin-dom の範囲でも) は便利です。SQL Server 2005 ではスキーマがサポートされているため、プレフィックスはあまり役に立ちません。これは、名前のプレフィックスと同じように、さまざまな種類の名前空間に使用できます。たとえば、スター スキーマでは、dimスキーマとファクトスキーマを使用して、この規則に従ってテーブルを参照できます。

ストアド プロシージャの場合、プレフィックスは、システム sproc からアプリケーション sproc を識別するために役立ちます。 up_vs.sp_を使用すると、データ ディクショナリから非システム ストアド プロシージャを比較的簡単に識別できます。

于 2008-10-26T17:41:39.963 に答える
10

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

プレフィックス :

  • 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
于 2008-10-26T18:49:58.313 に答える
5

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

大規模なデータベースの場合は、スキーマまたはサブシステム名を追加します。たとえば、受信、購入などをグループ化して保持します (SQL サーバーはアルファベット順に表示することを好むため)。

わかりやすくするために、名前に省略形を使用しないようにしています (プロジェクトの新しい人は、sproc の名前が uspUsingNoAbbreviationsIncreasesClarityForEveryone であるため、「UNAICFE」が何を表しているのか疑問に思う必要はありません)。

于 2008-10-26T17:16:42.370 に答える
4

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

表記:

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

例:

P_CMS_USER_UserInfoGet

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

  • 非常に単純なプレフィックスで開始すると、プレフィックスで始まるオブジェクトのみを実行するようにコードを記述できます(たとえば、SQLインジェクションを減らすため)。
  • 大規模な環境では、複数のチームが同じデータベースアーキテクチャで実行されるさまざまなアプリに取り組んでいます。アプリケーション表記は、どのグループがSPを所有するかを指定します。
  • ModuleセクションとNameセクションは、単に階層を完成させます。すべての名前は、階層からグループ/アプリ、モジュール、機能に一致できる必要があります。
于 2008-10-26T21:02:24.317 に答える
4

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

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

于 2008-10-26T17:09:05.147 に答える
2

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

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

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

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

于 2008-10-26T23:11:52.543 に答える
2

私はいつも使用します:

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

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

  • uspUserCreate
  • uspUserSelect
  • uspUserSelectByNetworkID

手順は、テーブル名と機能のアルファベット順に並べられているため、特定のテーブルに対して何ができるかを簡単に確認できます。プレフィックス「usp」を使用すると、(たとえば) 他のプロシージャ、複数のテーブル、関数、ビュー、およびサーバーと対話する 1000 行のプロシージャを作成している場合に、何を呼び出しているかがわかります。

SQL Server IDE のエディターが Visual Studio と同等になるまでは、プレフィックスをそのまま使用します。

于 2008-10-26T17:54:22.233 に答える
2

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

使用する操作接頭辞 -

  • "<em>get" – レコードセットを返します
  • “<em>ins” – データを挿入します
  • 「<em>upd」 – データを更新
  • 「<em>del」 – データを削除します

例えば

wmt_ins_customer_details

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

利点

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

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

これまでのところ、このアプローチの欠点に遭遇していません。

于 2008-10-26T18:45:35.420 に答える
1

usp_ 命名規則は何の役にも立たないと思います。

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

于 2008-10-26T17:17:49.763 に答える
1

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

従来の制約がなければ、接頭辞を使用していないことは間違いありません。

通常、接頭辞の後に SP 名を開始し、その手順が何を行うかを説明する動詞を付けてから、操作対象のエンティティの名前を付けます。エンティティ名の複数形は許可されています - 読みやすさを重視して、名前だけでプロシージャが何をするのかが明確になるようにしています。

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

shopGetCategories
shopUpdateItem
于 2008-10-26T17:20:05.780 に答える
1

論理的で一貫性がある限り、プレフィックスが正確に何であるかは実際には問題ではないと思います。個人的に使ってます

spu_[動作説明][処理説明]

ここで、アクションの説明は、get、set、archive、insert、delete などの典型的なアクションの一部です。プロセスの説明は、短くても説明的なものです。たとえば、

spu_archiveCollectionData 

また

spu_setAwardStatus

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

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

于 2008-10-26T17:38:55.197 に答える
1

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

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

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

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

Proc_Poll_Interface, Proc_Inv_Interface

これにより、POLL のジョブとインベントリなどのジョブを実行するすべてのストアド プロシージャを見つけることができます。

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

その他の機能の例。

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

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

proc が 1 つの名前で処理できる以上の機能を実行した場合、proc が必要以上に多くのことを行っていることを意味し、それらを再度分割する必要があります。

それが役立つことを願っています。

于 2008-10-26T17:58:33.673 に答える
1

スレッドに遅れて参加しましたが、ここに返信を入力したいと思います。

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

データを取得する場合: s<テーブル名>_G
データを削除する場合: s<テーブル名>_D
データを挿入する場合: s<テーブル名>_I
データを更新する場合: s<テーブル名>_U

この命名規則は、単語dtを接頭辞としてフロントエンドでも使用されます。

例:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

アプリケーションの上記の命名規則の助けを借りて、適切で覚えやすい名前が得られます。

2 番目のプロジェクトでは、同じ命名規則を使用しましたが、わずかな違いがあります。

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

例:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU
于 2009-06-13T22:32:58.493 に答える