Wie lautet Ihre Namenskonvention für gespeicherte Prozeduren? [geschlossen]

Ich habe verschiedene Regeln für die Benennung gespeicherter Prozeduren gesehen.

Einige Leute stellen dem sproc-Namen usp_ voran, andere mit einer Abkürzung für den App-Namen und wieder andere mit einem Eigentümernamen. Sie sollten sp_ in SQL Server nicht verwenden, es sei denn, Sie meinen es wirklich so.

Einige beginnen den Proc-Namen mit einem Verb (Get, Add, Save, Remove). Andere betonen die Entitätsnamen.

In einer Datenbank mit Hunderten von Sprocs kann es sehr schwierig sein, einen geeigneten Sproc zu finden, wenn Sie glauben, dass bereits einer vorhanden ist. Namenskonventionen können das Auffinden eines Sprocs erleichtern.

Verwenden Sie eine Namenskonvention? Bitte beschreiben Sie es und erklären Sie, warum Sie es anderen Optionen vorziehen.

Zusammenfassung der Antworten:

• Jeder scheint die Konsistenz der Benennung zu befürworten, so dass es für jeden wichtiger sein könnte, dieselbe Namenskonvention zu verwenden, als welche bestimmte verwendet wird.
• Präfixe: Während viele Leute usp_ oder ähnliches verwenden (aber selten sp_), verwenden viele andere Datenbank- oder App-Namen. Ein cleverer DBA verwendet gen, rpt und tsk, um allgemeine CRUD-Sprocs von denen zu unterscheiden, die für Berichte oder Aufgaben verwendet werden.
• Verb + Nomen scheint etwas beliebter zu sein als Nomen + Verb. Einige Benutzer verwenden die SQL-Schlüsselwörter (Auswählen, Einfügen, Aktualisieren, Löschen) für die Verben, während andere Nicht-SQL-Verben (oder Abkürzungen für sie) wie Get und Add verwenden. Einige unterscheiden zwischen Singluar- und Plural-Substantiven, um anzugeben, ob ein oder mehrere Datensätze abgerufen werden.
• Gegebenenfalls wird am Ende ein zusätzlicher Satz vorgeschlagen. GetCustomerById, GetCustomerBySaleDate.
• Einige Leute verwenden Unterstriche zwischen den Namenssegmenten, andere vermeiden Unterstriche. app_ Get_Customer vs. appGetCustomer - Ich denke, es ist eine Frage der Lesbarkeit.
• Große Sammlungen von Sprocs können in Oracle-Pakete oder Management Studio-Lösungen und -Projekte (SQL Server) oder SQL Server-Schemas aufgeteilt werden.
• Undurchschaubare Abkürzungen sollten vermieden werden.

Warum ich die Antwort gewählt habe: Es gibt so viele gute Antworten. Danke euch allen! Wie Sie sehen können, wäre es sehr schwierig, nur einen auszuwählen. Der, den ich gewählt habe, hat mich beeindruckt. Ich bin dem gleichen Weg gefolgt, den er beschreibt - ich habe versucht, Verb + Nomen zu verwenden und dann nicht alle Sprocs zu finden, die für den Kunden gelten.

Es ist sehr wichtig, einen vorhandenen Sproc lokalisieren zu können oder festzustellen, ob überhaupt einer existiert. Schwerwiegende Probleme können auftreten, wenn jemand versehentlich einen doppelten Sproc mit einem anderen Namen erstellt.

Da ich im Allgemeinen an sehr großen Apps mit Hunderten von Sprocs arbeite, bevorzuge ich die am einfachsten zu findende Benennungsmethode. Für eine kleinere App könnte ich Verb + Nomen befürworten, da es der allgemeinen Codierungskonvention für Methodennamen folgt.

Er befürwortet auch das Präfixieren des App-Namens anstelle des nicht sehr nützlichen usp_. Wie mehrere Personen betonten, enthält die Datenbank manchmal Sprocs für mehrere Apps. Das Präfixieren des App-Namens hilft also, die Sprocs zu trennen UND DBAs und anderen zu helfen, zu bestimmen, für welche App der Sproc verwendet wird.

Für mein letztes Projekt habe ich usp_ [Action] [Object] [Process] verwendet, also zum Beispiel usp_AddProduct oder usp_GetProductList, usp_GetProductDetail. Jetzt hat die Datenbank jedoch mehr als 700 Prozeduren. Es wird viel schwieriger, alle Prozeduren für ein bestimmtes Objekt zu finden. Zum Beispiel muss ich jetzt 50 ungerade Add-Prozeduren für das Produkt hinzufügen und 50 ungerade für das Get usw. suchen.

Aus diesem Grund plane ich in meiner neuen Anwendung, Prozedurnamen nach Objekt zu gruppieren. Außerdem lösche ich den USP, da ich der Meinung bin, dass er etwas überflüssig ist, abgesehen davon, dass es sich um eine Prozedur handelt, die ich vom Namen von abziehen kann das Verfahren selbst.

Das neue Format lautet wie folgt

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

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

Es ist hilfreich, Dinge zu gruppieren, um sie später leichter finden zu können, insbesondere wenn eine große Anzahl von Sprocs vorhanden ist.

In Bezug darauf, wo mehr als ein Objekt verwendet wird, stelle ich fest, dass die meisten Instanzen ein primäres und ein sekundäres Objekt haben, sodass das primäre Objekt in der normalen Instanz verwendet wird und auf das sekundäre im Prozessabschnitt verwiesen wird, beispielsweise App_Product_AddAttribute.

Hier einige Erläuterungen zum Problem mit dem Präfix sp_ in SQL Server.

Gespeicherte Prozeduren mit dem Präfix sp_ sind System-Sprocs, die in der Master-Datenbank gespeichert sind.

Wenn Sie Ihrem Sproc dieses Präfix geben, sucht SQL Server zuerst in der Master-Datenbank und dann in der Kontextdatenbank nach ihnen und verschwendet so unnötig Ressourcen. Wenn der vom Benutzer erstellte Sproc denselben Namen wie ein System-Sproc hat, wird der vom Benutzer erstellte Sproc nicht ausgeführt.

Das Präfix sp_ gibt an, dass auf den Sproc von allen Datenbanken aus zugegriffen werden kann, dass er jedoch im Kontext der aktuellen Datenbank ausgeführt werden sollte.

Hier ist eine nette Erklärung, die eine Demo des Performance-Hits enthält.

Hier ist eine weitere hilfreiche Quelle, die Ant in einem Kommentar zur Verfügung gestellt hat.

Ungarische Systeme (wie das obige Präfix "usp") lassen mich schaudern.

Wir teilen viele gespeicherte Prozeduren in verschiedenen, ähnlich strukturierten Datenbanken. Daher verwenden wir für datenbankspezifische Datenbanken ein Präfix des Datenbanknamens selbst. Gemeinsame Prozeduren haben kein Präfix. Ich nehme an, die Verwendung verschiedener Schemata könnte eine Alternative sein, um solche etwas hässlichen Präfixe insgesamt zu entfernen.

Der tatsächliche Name nach dem Präfix unterscheidet sich kaum von der Funktionsbenennung: In der Regel ein Verb wie "Hinzufügen", "Setzen", "Generieren", "Berechnen", "Löschen" usw., gefolgt von mehreren spezifischeren Substantiven wie "Benutzer" "," DailyRevenues "und so weiter.

Antwort auf Ants Kommentar:

1. Der Unterschied zwischen einer Tabelle und einer Ansicht ist für diejenigen relevant, die das Datenbankschema entwerfen, nicht für diejenigen, die auf dessen Inhalt zugreifen oder diesen ändern. In dem seltenen Fall, dass Schemaspezifikationen benötigt werden, ist es leicht zu finden. Für die gelegentliche SELECT-Abfrage ist dies irrelevant. Tatsächlich halte ich es für einen großen Vorteil, Tabellen und Ansichten gleich behandeln zu können.
2. Im Gegensatz zu Funktionen und gespeicherten Prozeduren beginnt der Name einer Tabelle oder Ansicht wahrscheinlich nicht mit einem Verb oder ist alles andere als ein oder mehrere Substantive.
3. Für eine Funktion muss das Schema-Präfix aufgerufen werden. Tatsächlich unterscheidet sich die Aufrufsyntax (die wir sowieso verwenden) stark zwischen einer Funktion und einer gespeicherten Prozedur. Aber selbst wenn dies nicht der Fall wäre, würde das Gleiche wie 1. gelten: Wenn ich Funktionen und gespeicherte Prozeduren gleich behandeln kann, warum sollte ich das nicht tun?

Ich habe im Laufe der Jahre so ziemlich alle verschiedenen Systeme verwendet. Ich habe endlich dieses entwickelt, das ich heute noch benutze:

Präfix :

• gen - Allgemein: Meistens CRUD
• rpt - Bericht: selbsterklärend
• tsk - Aufgabe: normalerweise etwas mit prozeduraler Logik, das über geplante Jobs ausgeführt wird

Aktionsspezifizierer:

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

(In Fällen, in denen die Prozedur viele Aufgaben ausführt, wird das Gesamtziel zur Auswahl des Aktionsspezifizierers verwendet. Beispielsweise erfordert ein INSERT des Kunden möglicherweise viel Vorbereitungsarbeit, das Gesamtziel ist jedoch INSERT, sodass "Ins" ausgewählt wird.

Objekt:

Bei gen (CRUD) ist dies der betroffene Tabellen- oder Ansichtsname. Für rpt (Bericht) ist dies die kurze Beschreibung des Berichts. Für tsk (Aufgabe) ist dies die kurze Beschreibung der Aufgabe.

Optionale Klärer:

Dies sind optionale Informationen, die zum besseren Verständnis der Prozedur verwendet werden. Beispiele sind "By", "For" usw.

Format:

[Präfix] [Aktionsspezifizierer] [Entität] [Optionale Klärer]

Beispiele für Prozedurnamen:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

TableName_WhatItDoes

• Comment_GetByID

• Kundenliste

• UserPreference_DeleteByUserID

Keine Präfixe oder alberner ungarischer Unsinn. Nur der Name der Tabelle, mit der sie am engsten verbunden ist, und eine kurze Beschreibung ihrer Funktionsweise.

Eine Einschränkung: Ich persönlich stelle allen meinen automatisch generierten CRUD immer zCRUD_ voran, damit es bis zum Ende der Liste sortiert wird, wo ich es nicht ansehen muss.

Das Starten eines gespeicherten Prozedurnamens mit sp_ist in SQL Server fehlerhaft, da alle System-Sprocs mit sp_ beginnen. Eine konsistente Benennung (auch im Ausmaß von hobgoblin-dom) ist nützlich, da sie automatisierte Aufgaben basierend auf dem Datenwörterbuch erleichtert. Präfixe sind in SQL Server 2005 etwas weniger nützlich, da sie Schemas unterstützen, die für verschiedene Arten von Namespaces verwendet werden können, wie Präfixe für Namen, die früher verwendet wurden. Zum Beispiel könnte man in einem Sternschema Dim- und Fact- Schemata haben und nach dieser Konvention auf Tabellen verweisen.

Bei gespeicherten Prozeduren ist das Präfix nützlich, um Anwendungs-Sprocs von System-Sprocs zu unterscheiden. up_vs. sp_macht es relativ einfach, nicht vom System gespeicherte Prozeduren aus dem Datenwörterbuch zu identifizieren.

Ich kapsle die gespeicherten Prozeduren immer in Paketen (ich verwende Oracle bei der Arbeit). Dadurch wird die Anzahl der separaten Objekte reduziert und die Wiederverwendung von Code erleichtert.

Die Namenskonvention ist Geschmackssache und sollte bei Projektstart mit allen anderen Entwicklern übereinstimmen.

Für kleine Datenbanken verwende ich uspTableNameOperationName, z. B. uspCustomerCreate, uspCustomerDelete usw. Dies erleichtert die Gruppierung nach 'Hauptentität'.

Fügen Sie für größere Datenbanken einen Schema- oder Subsystemnamen hinzu, z. B. Empfangen, Kaufen usw., um sie gruppiert zu halten (da SQL Server sie gerne alphabetisch anzeigt).

Ich versuche aus Gründen der Klarheit, Abkürzungen in den Namen zu vermeiden (und neue Leute im Projekt müssen sich nicht fragen, wofür 'UNAICFE' steht, da der Sproc uspUsingNoAbbreviationsIncreasesClarityForEveryone heißt.)

Ich verwende derzeit ein Format wie das folgende

Notation:

[PREFIX] [ANWENDUNG] [MODUL] _ [NAME]

Beispiel:

P_CMS_USER_UserInfoGet

Ich mag diese Notation aus mehreren Gründen:

• Beginnend mit einem sehr einfachen Präfix kann Code geschrieben werden, um nur Objekte auszuführen, die mit dem Präfix beginnen (z. B. um die SQL-Injection zu reduzieren).
• In unserer größeren Umgebung arbeiten mehrere Teams an verschiedenen Apps, die dieselbe Datenbankarchitektur verwenden. Die Anwendungsnotation gibt an, welcher Gruppe der SP gehört.
• Die Abschnitte Modul und Name vervollständigen einfach die Hierarchie. Alle Namen sollten in der Lage sein, mit Gruppe / App, Modul, Funktion aus der Hierarchie abgeglichen zu werden.

Ich benutze immer:

usp [Tabellenname] [Aktion] [Zusätzliches Detail]

Bei einer Tabelle mit dem Namen "tblUser" habe ich Folgendes:

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

Die Prozeduren sind alphabetisch nach Tabellennamen und Funktionen sortiert, sodass Sie leicht erkennen können, was ich mit einer bestimmten Tabelle tun kann. Wenn Sie das Präfix "usp" verwenden, weiß ich, was ich aufrufe, wenn ich (zum Beispiel) eine Prozedur mit 1000 Zeilen schreibe, die mit anderen Prozeduren, mehreren Tabellen, Funktionen, Ansichten und Servern interagiert.

Bis der Editor in der SQL Server-IDE so gut wie Visual Studio ist, behalte ich die Präfixe.

application prefix_ operation prefix_ Beschreibung der beteiligten Datenbankobjekte (abzüglich der Leerzeichen zwischen den Unterstrichen - mussten Leerzeichen eingefügt werden, damit sie angezeigt werden ) .

Operationspräfixe, die wir verwenden -

• „ Hol " - gibt ein Recordset zurück
• " Ins " - fügt Daten ein
• " Upd " - aktualisiert die Daten
• " Del " - löscht Daten

z.B

wmt_ ins _ customer _details

"Workforce Management Tool, Details in Kundentabelle einfügen"

Vorteile

Alle gespeicherten Prozeduren, die sich auf dieselbe Anwendung beziehen, werden nach Namen gruppiert. Innerhalb der Gruppe werden gespeicherte Prozeduren, die dieselbe Art von Operation ausführen (z. B. Einfügungen, Aktualisierungen usw.), zusammengefasst.

Dieses System funktioniert gut für uns, mit ca. 1000 gespeicherte Prozeduren in einer Datenbank auf Anhieb.

Bisher sind bei diesem Ansatz keine Nachteile aufgetreten.

GetXXX - Ruft XXX basierend auf @ID ab

GetAllXXX - Ruft alle XXX ab

PutXXX - Fügt XXX ein, wenn die übergebene @ID -1 ist; sonst Updates

DelXXX - Löscht XXX basierend auf @ID

Ich denke, die usp_-Namenskonvention nützt niemandem etwas.

In der Vergangenheit habe ich für CRUD-Operationen Präfixe zum Abrufen / Aktualisieren / Einfügen / Löschen verwendet, aber jetzt, da ich Linq to SQL oder EF verwende, um den größten Teil meiner CRUD-Arbeit zu erledigen, sind diese vollständig verschwunden. Da ich in meinen neuen Anwendungen so wenige Procs gespeichert habe, spielen die Namenskonventionen keine Rolle mehr wie früher ;-)

Für die aktuelle Anwendung, an der ich arbeite, haben wir ein Präfix, das den Anwendungsnamen identifiziert (vier Kleinbuchstaben). Der Grund dafür ist, dass unsere Anwendung mit einer Legacy-Anwendung in derselben Datenbank koexistieren muss. Daher ist das Präfix ein Muss.

Wenn wir nicht die Legacy-Einschränkung hätten, bin ich mir ziemlich sicher, dass wir kein Präfix verwenden würden.

Nach dem Präfix beginnen wir den SP-Namen normalerweise mit einem Verb, das beschreibt, was die Prozedur tut, und dann mit dem Namen der Entität, mit der wir arbeiten. Die Pluralisierung des Entitätsnamens ist zulässig. Wir versuchen, die Lesbarkeit zu betonen, damit aus dem Namen ersichtlich wird, was die Prozedur allein tut.

Typische Namen für gespeicherte Prozeduren in unserem Team sind:

shopGetCategories
shopUpdateItem

Ich denke nicht, dass es wirklich wichtig ist, was genau Ihr Präfix ist, solange Sie logisch und konsistent sind. Persönlich benutze ich

spu_ [Aktionsbeschreibung] [Prozessbeschreibung]

Dabei handelt es sich bei der Aktionsbeschreibung um eine kleine Auswahl typischer Aktionen wie Abrufen, Festlegen, Archivieren, Einfügen, Löschen usw. Die Prozessbeschreibung ist beispielsweise kurz, aber beschreibend

spu_archiveCollectionData 

oder

spu_setAwardStatus

Ich benenne meine Funktionen ähnlich, aber mit dem Präfix udf_

Ich habe Leute gesehen, die versucht haben, die pseudo-ungarische Notation für die Benennung von Prozeduren zu verwenden, was meiner Meinung nach mehr verbirgt, als es verrät. Solange ich meine Prozeduren alphabetisch aufliste, sehe ich sie nach Funktionen gruppiert. Für mich scheint dies der Sweet Spot zwischen Ordnung und unnötiger Genauigkeit zu sein

Vermeiden Sie sp_ * auf dem SQl-Server, da alle im System gespeicherten Vorgänge mit sp_ beginnen. Daher wird es für das System schwieriger, das dem Namen entsprechende Objekt zu finden.

Wenn Sie also mit etwas anderem als sp_ ​​beginnen, werden die Dinge einfacher.

Daher verwenden wir zunächst eine allgemeine Benennung von Proc_. Dies erleichtert die Identifizierung der Prozeduren, wenn eine große Schemadatei angezeigt wird.

Außerdem weisen wir ein Präfix zu, das die Funktion identifiziert. Mögen

Proc_Poll_Interface, Proc_Inv_Interface etc.

Dies ermöglicht es uns, alle gespeicherten Prozesse zu finden, die die Aufgabe von POLL erfüllen, im Gegensatz zu Inventar usw.

Wie auch immer, das Präfixsystem hängt von Ihrer Problemdomäne ab. Aber alles, was gesagt und getan wurde, sollte vorhanden sein, auch wenn es nur darum geht, den Leuten zu ermöglichen, die gespeicherte Prozedur im Explorer-Dropdown zur Bearbeitung schnell zu lokalisieren.

andere zB von Funktion.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Wir folgten der funktionsbasierten Benennung, da Procs eher Code / Funktion als statische Objekte wie Tabellen ähneln. Es hilft nicht, dass Procs mit mehr als einer Tabelle arbeiten kann.

Wenn der Proc mehr Funktionen ausgeführt hat, als in einem einzigen Namen ausgeführt werden können, bedeutet dies, dass Ihr Proc viel mehr als nötig tut und es Zeit ist, sie erneut zu teilen.

Hoffentlich hilft das.

Ich bin dem Thread spät beigetreten, möchte aber meine Antwort hier eingeben:

In meinen letzten beiden Projekten gibt es unterschiedliche Trends, wie in einem, das wir verwendet haben:

So rufen Sie Daten ab: s <Tabellenname> _G
So löschen Sie Daten: s <Tabellenname> _D
So fügen Sie Daten ein: s <Tabellenname> _I
So aktualisieren Sie Daten: s <Tabellenname> _U

Diesen Namenskonventionen folgt auch im Frontend das Präfix des Wortes dt .

Beispiel:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

Mit Hilfe der oben genannten Namenskonventionen in unserer Anwendung haben wir gute und leicht zu merkende Namen.

Während wir im zweiten Projekt die gleichen Namenskonventionen mit geringem Unterschied verwendeten:

So rufen Sie Daten ab: sp_ <Tabellenname> G
So löschen Sie Daten: sp_ <Tabellenname> D
So fügen Sie Daten ein: sp_ <Tabellenname> I
So aktualisieren Sie Daten: sp_ <Tabellenname> U.

Beispiel:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU