it-swarm.com.de

Was ist Ihre Namenskonvention für gespeicherte Prozeduren?

Ich habe verschiedene Regeln zum Benennen gespeicherter Prozeduren gesehen.

Einige Leute stellen dem Sproc-Namen usp_ voran, andere eine Abkürzung für den App-Namen und wieder andere einen Eigentümernamen. Sie sollten sp_ nicht in SQL Server verwenden, es sei denn, Sie meinen es ernst.

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 einer bereits 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 Möglichkeiten vorziehen.

Zusammenfassung der Antworten:

  • Jeder scheint für eine einheitliche Benennung zu plädieren, dass es für jeden wichtiger sein könnte, dieselbe Benennungskonvention zu verwenden, als diejenige, die 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 unterscheidet mit gen, rpt und tsk allgemeine CRUD-Sprocs von denen, die für Berichte oder Aufgaben verwendet werden.
  • Verb + Nomen scheint etwas populärer zu sein als Nomen + Verb. Einige Leute 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 Pluralnomen, um anzuzeigen, ob ein oder mehrere Datensätze abgerufen werden.
  • Gegebenenfalls wird am Ende ein zusätzlicher Satz vorgeschlagen. GetCustomerById, GetCustomerBySaleDate.
  • Einige Personen 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-Schemata unterteilt werden.
  • Undurchschaubare Abkürzungen sollten vermieden werden.

Warum ich die Antwort gewählt habe: Es gibt SO viele gute Antworten. Vielen Dank! Wie Sie sehen, wäre es sehr schwierig, nur eine zu wählen. Die von mir gewählte Methode ist bei mir angekommen. Ich bin den gleichen Weg gegangen, den er beschrieben hat: Ich habe versucht, Verb + Noun zu verwenden, und konnte dann nicht alle für den Kunden zutreffenden Sprocs finden.

Es ist sehr wichtig, in der Lage zu sein, einen vorhandenen Sproc zu lokalisieren oder festzustellen, ob einer überhaupt existiert. Schwerwiegende Probleme können auftreten, wenn versehentlich ein Duplikat eines Sprocs mit einem anderen Namen erstellt wird.

Da ich in der Regel an sehr großen Apps mit Hunderten von Sprocs arbeite, bevorzuge ich die am einfachsten zu findende Benennungsmethode. Für eine kleinere App würde ich Verb + Nomen empfehlen, da es der allgemeinen Kodierungskonvention für Methodennamen folgt.

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

118
DOK

Für mein letztes Projekt habe ich usp_ [Action] [Object] [Process] verwendet, also zum Beispiel usp_AddProduct oder usp_GetProductList, usp_GetProductDetail. Inzwischen sind jedoch mehr als 700 Prozeduren in der Datenbank vorhanden, und es wird sehr viel schwieriger, alle Prozeduren für ein bestimmtes Objekt zu finden. Zum Beispiel muss ich jetzt nach 50 ungeraden Hinzufügungsprozeduren für die Produkthinzufügung und nach 50 ungeraden für das Erhalten usw. suchen.

Aus diesem Grund plane ich in meiner neuen Anwendung, Prozedurnamen nach Objekten zu gruppieren. Außerdem lösche ich das usp, da ich der Meinung bin, dass es etwas überflüssig ist, außer mir eine Prozedur mitzuteilen, die ich aus dem Namen von ableiten 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 hilft, Dinge zu gruppieren, um sie später leichter zu finden, insbesondere wenn es eine große Anzahl von Sprocs gibt.

In Bezug auf die Verwendung von mehr als einem Objekt habe ich festgestellt, 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 Objekt im Prozessabschnitt verwiesen wird, z. B. App_Product_AddAttribute.

65
dnolan

Hier einige Erläuterungen zum Problem mit dem sp_-Präfix 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 Masterdatenbank und dann in der Kontextdatenbank nach ihnen, wodurch unnötigerweise Ressourcen verschwendet werden. Wenn der vom Benutzer erstellte Sproc denselben Namen wie ein Systemsproc 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 Leistungstreffers enthält.

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

34
DOK

Systems Hungarian (wie das obige "usp" -Präfix) lässt mich schaudern.

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

Der tatsächliche Name nach dem Präfix unterscheidet sich kaum von der Benennung von Funktionen: in der Regel ein Verb wie "Hinzufügen", "Festlegen", "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 den Inhalt zugreifen oder ihn ändern. In den seltenen Fällen, in denen Schemaspezifikationen erforderlich sind, ist dies leicht zu finden. Für die gelegentliche SELECT-Abfrage ist dies irrelevant. Tatsächlich sehe ich es als großen Vorteil an, Tabellen und Ansichten gleich behandeln zu können.
  2. Anders als bei Funktionen und gespeicherten Prozeduren wird der Name einer Tabelle oder Ansicht wahrscheinlich nicht mit einem Verb beginnen oder etwas anderes als ein oder mehrere Substantive sein.
  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?
16
Sören Kuklau

Starten eines gespeicherten Prozedurnamens mitsp_ ist in SQL Server fehlerhaft, da die System-Sprocs alle mit sp_ beginnen. Eine konsistente Benennung (auch in Bezug auf hobgoblin-dom) ist hilfreich, da sie automatisierte Aufgaben auf der Grundlage des Datenwörterbuchs ermöglicht. Präfixe sind in SQL Server 2005 etwas weniger nützlich, da sie Schemas unterstützen, die für verschiedene Typen von Namespaces in der Art und Weise verwendet werden können, wie Präfixe für Namen verwendet werden. Beispielsweise 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, gespeicherte Nicht-Systemprozeduren aus dem Datenwörterbuch zu identifizieren.

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

Präfix :

  • general: Hauptsächlich CRUD
  • rpt - Bericht: selbsterklärend
  • tsk - Task: normalerweise etwas mit prozeduraler Logik, ausgeführt über geplante Jobs

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 Kunden-INSERT möglicherweise viel Vorarbeit, aber das Gesamtziel ist INSERT, daher wird "Ins" ausgewählt.

Objekt:

Bei gen (CRUD) ist dies der Name der betroffenen Tabelle oder Ansicht. Für rpt (Bericht) ist dies die Kurzbeschreibung des Berichts. Für tsk (Task) ist dies die Kurzbeschreibung der Task.

Optionale Klärer:

Hierbei handelt es sich um optionale Informationen, die zum besseren Verständnis des Verfahrens verwendet werden. Beispiele sind "By", "For" usw.

Format:

[Präfix] [Aktionsspezifizierer] [Entität] [Optionale Erklärungen]

Beispiele für Prozedurnamen:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection
9
Pittsburgh DBA

TableName_WhatItDoes

  • Comment_GetByID

  • Kundenliste

  • UserPreference_DeleteByUserID

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

Eine Einschränkung: Ich persönlich stelle meiner automatisch generierten CRUD immer das Präfix zCRUD_ voran, damit sie an das Ende der Liste gelangt, wo ich sie nicht ansehen muss.

9
Jason Kester

Ich verwende derzeit ein Format wie das folgende

Notation:

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

Beispiel:

P_CMS_USER_UserInfoGet

Ich mag diese Notation aus ein paar Gründen:

  • mit einem sehr einfachen Präfix zu beginnen, ermöglicht das Schreiben von Code, um nur Objekte auszuführen, die mit dem Präfix beginnen (zum Beispiel 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 Module und Name vervollständigen einfach die Hierarchie. Alle Namen sollten in der Lage sein, mit Group/App, Module, Function von der Erbe verglichen zu werden.
4
pearcewg

Ich kapsle die gespeicherten Prozeduren immer in Pakete (ich verwende Oracle bei der Arbeit). Dies reduziert die Anzahl separater Objekte und hilft bei der Wiederverwendung von Code.

Die Namenskonvention ist Geschmackssache und sollte bei Projektstart mit allen anderen Entwicklern abgestimmt werden.

4

für kleine Datenbanken verwende ich uspTableNameOperationName, z. uspCustomerCreate, uspCustomerDelete usw. Dies erleichtert die Gruppierung nach "Haupt" -Entität.

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

ich versuche, Abkürzungen in den Namen aus Gründen der Klarheit zu vermeiden (und neue Leute im Projekt müssen sich nicht fragen, wofür 'UNAICFE' steht, weil der Sproc den Namen uspUsingNoAbbreviationsIncreasesClarityForEveryone trägt).

4
Steven A. Lowe

Ich benutze immer:

usp [Tabellenname] [Aktion] [Extra Detail]

Bei einer Tabelle mit dem Namen "tblUser" erhalte ich:

  • uspUserCreate
  • uspUserSelect
  • uspUserSelectByNetworkID

Die Prozeduren sind alphabetisch nach Tabellennamen und Funktionalität sortiert, sodass Sie leicht sehen können, was ich mit einer bestimmten Tabelle tun kann. Wenn ich das Präfix "usp" verwende, erfahre ich, wie ich aufrufe, wenn ich beispielsweise eine Prozedur mit 1000 Zeilen schreibe, die mit anderen Prozeduren, mehreren Tabellen, Funktionen, Ansichten und Servern interagiert.

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

2
Ant

application prefix_ operation prefix_ Beschreibung der beteiligten Datenbankobjekte (abzüglich der Leerzeichen zwischen den Unterstrichen - musste Leerzeichen einfügen, damit sie angezeigt werden) .

operationspräfixe, die wir verwenden -

  • " get " - 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 zusammengefasst. 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.

Bisher sind bei diesem Ansatz keine Nachteile aufgetreten.

2
Russ Cam

GetXXX - Erhält XXX basierend auf @ID

GetAllXXX - Erhält alle XXX

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

DelXXX - Löscht XXX basierend auf @ID

2
tsilb

Vermeiden Sie sp_ * in SQL Server, da alle im System gespeicherten Prozeduren mit sp_ beginnen und es daher für das System schwieriger wird, das Objekt zu finden, das dem Namen entspricht.

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

Daher verwenden wir zunächst eine allgemeine Bezeichnung für Proc_. Das macht es einfacher, die Prozeduren zu identifizieren, wenn eine große Schemadatei vorliegt.

Ansonsten vergeben wir ein Präfix, das die Funktion kennzeichnet. Mögen

Proc_Poll_Interface, Proc_Inv_Interface etc.

Dies ermöglicht es uns, alle gespeicherten Prozesse zu finden, die die Arbeit von POLL erledigen, im Gegensatz zu Inventory usw.

Wie auch immer, das Präfixsystem hängt von Ihrer Problemdomäne ab. Aber all das, was Sie gesagt und getan haben, sollte auch dann vorhanden sein, wenn es nur möglich sein soll, die gespeicherte Prozedur im Dropdown-Menü explorere zur Bearbeitung schnell zu lokalisieren.

andere zB's von Funktion.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Wir folgten der funktionsbasierten Namensgebung, da Procs eher Code/Funktion als statische Objekte wie Tabellen ähneln. Es hilft nicht, dass Procs möglicherweise mit mehr als einer Tabelle funktioniert.

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

Hoffentlich hilft das.

1
computinglife

Ich habe mich spät angemeldet, aber ich möchte meine Antwort hier eingeben:

In meinen letzten beiden Projekten gibt es verschiedene 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

Nach diesen Namenskonventionen wird im Frontend auch das Wort vorangestellt dt.

Beispiel:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

Mit Hilfe der obigen Namenskonventionen in unserer Anwendung haben wir einen guten und leicht zu merkenden Namen.

Während wir im zweiten Projekt die gleichen Namenskonventionen mit wenigen Unterschieden 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
1
Gaurav Aroraa

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

In der Vergangenheit habe ich für CRUD-Vorgänge die Präfixe Get/Update/Insert/Delete verwendet. Da ich jedoch Linq to SQL oder EF für die meisten meiner CRUD-Vorgänge verwende, 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 ;-)

1
Dave Markle

Für die aktuelle Anwendung, an der ich arbeite, haben wir ein Präfix, das den Namen der Anwendung angibt (vier Kleinbuchstaben). Der Grund dafür ist, dass unsere Anwendung in der Lage sein muss, zusammen mit einer älteren Anwendung in derselben Datenbank zu existieren, sodass das Präfix ein Muss ist.

Wenn wir die Vorgängerbedingung nicht hätten, bin ich mir ziemlich sicher, dass wir kein Präfix verwenden würden.

Nach dem Präfix beginnen wir normalerweise den Namen SP mit einem Verb, das beschreibt, was die Prozedur tut, und dann den Namen der Entität, mit der wir arbeiten. Eine Pluralisierung des Entitätsnamens ist zulässig - wir versuchen es um die Lesbarkeit zu betonen, so dass es offensichtlich ist, was die Prozedur allein aus dem Namen macht.

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

shopGetCategories
shopUpdateItem
1
driis

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

spu_ [Aktionsbeschreibung] [Prozessbeschreibung]

dabei ist die Aktionsbeschreibung eine von wenigen typischen Aktionen wie z. B. Abrufen, Festlegen, Archivieren, Einfügen, Löschen usw. Die Prozessbeschreibung ist kurz, aber beispielsweise 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 Prozedurnamen zu verwenden, was meiner Meinung nach mehr verbirgt, als es verrät. Solange ich meine Abläufe alphabetisch aufführe, sehe ich sie nach Funktionen gruppiert, scheint dies für mich der Sweet Spot zwischen Ordnung und unnötiger Strenge zu sein

1
Cruachan