Was ist Ihre Namenskonvention für gespeicherte Prozeduren?[geschlossen]

https://stackoverflow.com/questions/238267

04-07-2019
|

Frage

Ich habe gesehen, verschiedene Regeln für die Benennung von gespeicherten Prozeduren.

Einige Leute Präfix-die sproc name mit usp_, andere, die eine Abkürzung für den Namen der app, und noch andere mit einem Besitzer-name.Sie sollten nicht sp_ in SQL Server, wenn Sie wirklich bedeuten es.

Einige beginnen das proc-Namen mit a-verb (Get, Add, Save, Remove).Andere betonen die entity-name(s).

Auf eine Datenbank mit Hunderten von sprocs, kann es sehr schwer zu Blättern um und finden Sie ein passendes sproc wenn Sie denken, man ist bereits vorhanden.Namenskonventionen können machen das Auffinden einer sproc einfacher.

Verwenden Sie eine Namenskonvention?Bitte beschreiben Sie es und erklären Sie, warum Sie es lieber über andere Möglichkeiten.

Zusammenfassung der Antworten:

Jeder scheint zu befürworten, der Konsistenz, der Namensgebung, dass es möglicherweise mehr für jeden wichtig, verwenden Sie die gleiche Namenskonvention als das insbesondere verwendet wird.
Präfixe:Während viele Leute benutzen usp_ oder etwas ähnliches (aber selten sp_), viele andere nutzen die Datenbank-oder app-Namen.Ein DBA clever nutzt, gen -, rpt-und tsk zu unterscheiden Allgemeinen CRUD sprocs sich von denen für die Berichterstattung oder Aufgaben.
Verb + Substantiv zu sein scheint, etwas beliebter als Nomen + Verb.Einige Leute verwenden die SQL-Schlüsselwörter (Select, Insert, Update, Delete) für die Verben, während andere die Verwendung von nicht-SQL-Verben (oder Abkürzungen) wird wie Get und Add.Einige unterscheiden zwischen singluar-und plural Substantiven angeben, ob Sie eine oder viele Datensätze abgerufen werden.
Ein zusätzlicher Satz deutet sich am Ende, wo es angebracht ist.GetCustomerById, GetCustomerBySaleDate.
Einige Leute verwenden Sie Unterstriche zwischen den Namen Segmente, und einige vermeiden Sie Unterstriche.app_ Get_Customer vs.appGetCustomer-ich denke, es ist eine Frage der Lesbarkeit.
Große Sammlungen von sprocs können getrennt werden in Oracle-Pakete oder Management Studio (SQL Server) - Lösungen und Projekte, oder SQL Server-schemas.
Unergründlich Abkürzungen sollten vermieden werden.

Warum ich wählen Sie die Antwort, die ich habe: Es gibt SO viele gute Antworten.Danke Euch allen!Wie Sie sehen, wäre es sehr schwer, nur eine auszuwählen.Die eine, die ich wählte, in Resonanz mit mir.Ich folgte dem gleichen Weg, den er beschreibt,--, versucht die Verb + Substantiv-und dann nicht in der Lage zu finden, alle sprocs, die auf den Kunden zutrifft.

Zu können, suchen Sie eine vorhandene sproc, oder um festzustellen, ob man überhaupt existiert, ist sehr wichtig.Schwerwiegende Probleme können auftreten, wenn jemand versehentlich erstellt eine Kopie des sproc mit einem anderen Namen.

Da ich in der Regel auf sehr großen apps mit Hunderten von sprocs, ich habe eine Vorliebe für die einfachste-zu-finden-naming-Methode.Für eine kleinere app, ich könnte befürworten, Verb + Substantiv, wie es folgt die Allgemeinen Code-Konvention für die Methoden-Namen.

Er befürwortet auch das voranstellen app-Namen anstelle der nicht sehr nützlich usp_.Als mehrere Leute darauf hingewiesen, manchmal die Datenbank enthält sprocs für mehrere apps.So, Präfix mit den app-Namen hilft zu trennen die sprocs UND hilft Datenbankadministratoren und anderen zu bestimmen welche app die sproc verwendet wird.

Lösung

Für mein letztes Projekt i verwendet usp_ [Action] [Objekt] [Verfahren], so zum Beispiel usp_AddProduct oder usp_GetProductList, usp_GetProductDetail. Doch jetzt ist die Datenbank bei 700 Verfahren plus, es viel schwieriger wird, alle Verfahren auf ein bestimmtes Objekt zu finden. Zum Beispiel muß ich jetzt 50 ungerade Add Verfahren für die Produkte hinzufügen und 50 ungerade für das Erhalten etc suchen.

Aus diesem Grund in meiner neuen Anwendung, die ich auf Gruppierungsverfahren Namen von Objekt habe vor, ich bin fallen auch die usp wie ich fühle es etwas redundant ist, anders als mir zu sagen, es ist ein Verfahren, etwas, das ich abziehen kann aus der Name des Verfahrens selbst.

Das neue Format ist wie folgt

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

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

Es hilft, Gruppe Dinge einfachen Befund später, vor allem, wenn es eine große Menge an sprocs ist.

In Bezug auf, wo mehr als ein Objekt verwendet wird, finde ich, dass die meisten Fälle haben eine primäre und sekundäre Aufgabe, so dass die primäre Aufgabe in der normalen Instanz verwendet wird, und die sekundären im Verfahrensteil refered, zum Beispiel App_Product_AddAttribute.

Andere Tipps

Hier ist eine Aufklärung über die sp_ prefix Problem in SQL Server.

Gespeicherte Prozeduren mit den Namen mit dem Präfix sp_ system sprocs gespeichert in der Master-Datenbank.

Wenn Sie Ihr sproc dieses Präfix, sucht SQL Server für Sie in der Master-Datenbank zuerst, dann die Kontext-Datenbank, so werden unnötig Ressourcen verschwendet.Und, wenn der Benutzer erstellt sproc hat den gleichen Namen wie ein system sproc, die vom Benutzer erstellt sproc nicht ausgeführt werden.

Die sp_ prefix gibt an, dass die sproc zugänglich von allen Datenbanken, aber es sollte ausgeführt werden, in den Kontext der aktuellen Datenbank.

Hier s eine schöne Erklärung, die beinhaltet eine demo der performance-hit.

Hier s eine weitere hilfreiche Quelle zur Verfügung gestellt von Ant in einem Kommentar.

Systeme ungarische (wie der oben "usp" Präfix) machen mich schaudern.

Wir teilen viele gespeicherte Prozeduren in verschiedenen, ähnlich strukturierten Datenbanken, so dass für datenbankspezifische diejenigen, wir einen Präfix des Datenbanknamen verwenden selbst; Shared Verfahren haben keinen Präfix. Ich nehme an verschiedene Schemata verwendet könnte eine Alternative sein, um loszuwerden, so etwas hässlich Präfixe zusammen.

Der eigentliche Name nach dem Präfix unterscheidet sich kaum von der Funktion Namensgebung: in der Regel ein Verb wie „Add“, „Set“, „erzeugen“, „Berechnen“, „Löschen“, usw., gefolgt von mehreren spezifischeren Substantiven wie zur "Nutzer", "DailyRevenues", und so weiter.

Als Reaktion auf Ant Kommentar:

Der Unterschied zwischen einem Tisch und einem Blick ist relevant für diejenigen, die das Datenbankschema entwerfen, nicht diejenigen, die seinen Inhalt zugreifen oder modifizieren. Im seltenen Fall von Schema Besonderheiten benötigen, ist es einfach genug, um zu finden. Für die lässige SELECT-Abfrage ist es irrelevant. In der Tat halte ich in der Lage, Tabellen zu behandeln und sieht das gleiche wie ein großer Vorteil.
Im Gegensatz zu Funktionen und gespeicherten Prozeduren, der Name einer Tabelle oder Sicht unwahrscheinlich ist, mit einem Verb beginnen, oder irgendetwas sein, aber einem oder mehr Substantiven.
Eine Funktion erfordert das Schema Präfix aufgerufen werden. In der Tat ist die Aufruf-Syntax (die wir sowieso verwenden) sehr unterschiedlich zwischen einer Funktion und einer gespeicherten Prozedur. Aber auch wenn es nicht das gleiche wie 1. gelten würde: wenn ich Funktionen und gespeicherte Prozeduren gleich behandeln kann, warum sollte ich nicht

ein Name der gespeicherten Prozedur withsp_ Starten ist in SQL Server schlecht, weil das System sprocs alle mit sp_ starten. Konsistenter Name (auch in das Ausmaß von hobgoblin-dom) ist nützlich, weil es Aufgaben basierend auf dem Datenwörterbuch automatisiert facilititates. Präfixe sind etwas weniger nützlich in SQL Server 2005, wie es Schemata unterstützt, die für verschiedene Arten von Namensräumen in der Art und Weise verwendet werden kann, die verwendeten Namen Präfixe. Zum Beispiel auf einem Stern-Schema könnte man haben dim und Tatsache Schemata und beziehen sich auf Tabellen, die von dieser Konvention.

Für gespeicherte Prozeduren ist Vorfixierung nützlich für die Zwecke Anwendung sprocs von System sprocs von indentifying. up_ vs. sp_ macht es relativ einfach nicht-System gespeicherte Prozeduren aus dem Data Dictionary zu identifizieren.

TableName_WhatItDoes

Comment_GetByID
Customer_List
UserPreference_DeleteByUserID

Keine Präfixe oder albern ungarischen Unsinn. Nur der Name der Tabelle, es ist am ehesten im Zusammenhang mit, und eine kurze Beschreibung dessen, was es tut.

Eine Einschränkung auf die oben:. Ich persönlich immer alle meine automatisch generiert CRUD mit zCRUD_ Präfix, so dass es sortiert nach dem Ende der Liste, wo ich muß es nicht aussehen

Ich habe so ziemlich alle der verschiedenen Systeme im Laufe der Jahre. Ich entwickelte schließlich diese, die ich auch heute verwenden:

Prefix:

gen - Allgemein: CRUD, meist
rpt - Report: selbsterklärend
tsk - Aufgabe: in der Regel etwas mit Verfahrenslogik, laufen über geplante Aufträge

Aktion Anforderung:

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

(In den Fällen, in denen das Verfahren viele Dinge tun, ist das übergeordnete Ziel verwendet, um die Funktionsparameter zu wählen. Zum Beispiel kann ein Kunde INSERT eine Menge Vorbereitungsarbeit erfordern, aber das übergeordnete Ziel ist INSERT, so „In“ gewählt wird.

Objekt:

Für gen (CRUD), ist dies die Tabellen- oder Viewnamen betroffen. Für rpt (Report), das ist die kurze Beschreibung des Berichts. Für tsk (Aufgabe) ist dies die kurze Beschreibung der Aufgabe.

Optional Klär:

Diese sind optional Bits von Informationen verwendet, um das Verständnis des Verfahrens zu verbessern. Beispiele hierfür sind "durch", "Für", etc.

Format:

[Prefix] [Aktion Anforderung] [Entity] [Optional Klär]

Beispiele für Prozedurnamen:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

ich kapseln immer die gespeicherten Prozeduren in Pakete (I Oracle bin mit, bei der Arbeit). Das wird die Anzahl von separaten Objekten und Hilfe der Wiederverwendung von Code reduzieren.

Die Namenskonvention ist eine Frage des Geschmacks und etwas, das man mit allen anderen Entwicklern zu Projektbeginn zustimmen sollte.

für kleine Datenbanken, ich verwende uspTableNameOperationName, z.B. uspCustomerCreate, uspCustomerDelete etc. Dies erleichtert die Gruppierung von 'main' Einheit.

für größere Datenbanken, fügen Sie ein Schema oder Subsystemnamen, zum Beispiel Bekommen, Einkauf usw. zu halten sie zusammen gruppiert (da SQL Server mag sie alphabetisch angezeigt werden)

ich versuche Abkürzungen in den Namen zu vermeiden, für Klarheit (und neue Leute über das Projekt müssen nicht fragen, was ‚UNAICFE‘ steht für, weil die sproc heißt uspUsingNoAbbreviationsIncreasesClarityForEveryone)

Derzeit benutze ich ein format, wie in der folgenden

Notation:

[PREFIX][ANWENDUNG][MODULE]_[NAME]

Beispiel:

P_CMS_USER_UserInfoGet

Ich mag diese notation für ein paar Gründe:

beginnend mit sehr einfachen Präfix kann code geschrieben werden, um nur ausgeführt, Objekte beggining mit dem Präfix (um die SQL-injection, für Beispiel)
in unserer größeren Umgebung, mehrere teams arbeiten an verschiedenen apps, die mit dem gleichen Datenbank-Architektur.Die Anwendung notation bezeichnet die Gruppe besitzt das SP.
Das Modul und die Namen der Abschnitte füllen Sie einfach das folgende bietet.Alle Namen sollten in der Lage sein werden, abgestimmt auf die Gruppe/App, Modul, Funktion, die bietet.

ich immer wie folgt:

usp [Tabellenname] [Action] [Extra-Detail]

eine Tabelle namens "tblUser" gegeben, die mich gibt:

uspUserCreate
uspUserSelect
uspUserSelectByNetworkID

Die Verfahren sind alphabetisch nach Tabellennamen und nach Funktionalität sortiert, so ist es einfach zu sehen, was ich zu einem bestimmten Tisch tun. Unter Verwendung der Vorsilbe „usp“ lässt es mich wissen, was ich rufe, wenn ich (zum Beispiel) das Schreiben eines 1000-line Verfahren, die mit anderen Verfahren, mehrere Tabellen, Funktionen, Ansichten und Server.

interagiert

Bis der Editor in dem SQL Server-IDE ist so gut wie Visual Studio ich die Präfixe bin zu halten.

Anwendung prefix_ Betrieb prefix_ Beschreibung von Datenbankobjekten beteiligt . (Minus die Räume zwischen Unterstrichen - hatten Räume in setzen, für sie zu erscheinen)

Betrieb Präfixe verwenden wir -

„ get “ - gibt einen Re-Cord
„ in “ - fügen Daten
„ upd “ - Aktuelles Daten
„ del “ - löscht Daten

wmt_ in _ Kunde _details

"Arbeitskräfte-Management-Tool, Details einfügen in der Kundentabelle"

Vorteile

Alle im Zusammenhang gespeicherte Prozeduren derselben Anwendung zusammengefasst mit Namen. Innerhalb der Gruppe gespeicherte Prozeduren, die die gleiche Art von Operation durchführen (z Einfügungen, Aktualisierungen etc.) zusammengefasst sind.

Dieses System funktioniert gut für uns, ca. haben. 1000 gespeicherte Prozeduren in einer Datenbank aus der Spitze von meinem Kopf.

Haben über irgendwelche Nachteile dieses Ansatzes bisher nicht gekommen.

getXXX - Ruft XXX basierend auf @ID

GetAllXXX - Ruft alle XXX

PutXXX - Einsätze XXX wenn bestanden @ID -1; sonst Updates

DelXXX - Löscht XXX basierend auf @ID

Ich denke, die usp_ Namenskonvention hat niemand etwas Gutes.

In der Vergangenheit habe ich Get / Update / Insert / Löschen von Präfixen für CRUD-Operationen verwendet, aber jetzt, da ich Linq to SQL oder der EF verwenden die meisten meiner CRUD Arbeit zu tun, diese sind ganz verschwunden. Da ich so wenige gespeicherte Procs in meiner neuen Anwendungen haben, nicht die Namenskonventionen Rolle mehr, wie früher, -)

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

Wenn wir nicht das Erbe Einschränkung haben, bin ich ganz sicher, dass wir nicht einen Präfix werden.

Nach dem Präfix beginnen wir in der Regel den SP-Namen mit einem Verb, das beschreibt, was das Verfahren der Fall ist, und dann den Namen der Einheit, die wir operieren. Pluralisierung des Unternehmens Name ist erlaubt -. Wir versuchen, die Lesbarkeit zu betonen, so dass es offensichtlich ist, was die Prozedur tut aus dem Namen allein

Typische gespeicherte Prozedur Namen auf unserem Team seien:

shopGetCategories
shopUpdateItem

Ich glaube nicht wirklich wichtig ist genau das, was Ihr Präfix ist, solange Sie logisch und konsequent sind. Ich persönlich verwende

spu_ [action Beschreibung] [Prozessbeschreibung]

, wo Handlungsbeschreibung zu einer kleinen Reihe von typischen Aktionen ist wie erhalten, Set, Archiv, einfügen, löscht usw. Die Prozessbeschreibung ist etwas kurz, aber aussagekräftig, zum Beispiel

spu_archiveCollectionData

oder

spu_setAwardStatus

Ich nenne meine Funktionen ähnlich, aber Präfix mit UDF _

Ich habe Menschen pseudo-ungarische Notation für Verfahren Namensgebung verwenden gesehen versuchen, die meiner Meinung nach verbirgt sich mehr als es offenbart. Solange, wenn ich meine Prozeduren alphabetisch auflisten kann ich sie nach Funktionalität sortiert dann für mich, dass der Sweetspot zwischen Ordnung und unnötige Strenge

zu sein scheint

Vermeiden sp_* in SQl server, coz alle im system gespeicherten prcedures beginnt mit sp_ und daher wird es schwieriger für das system zu finden, das Objekt entsprechend den Namen.

Also, wenn Sie beginnen mit etwas anderem als sp_ Dinge einfacher geworden.

So verwenden wir eine gemeinsame Benennung von Proc_, um mit zu beginnen.Das macht es einfacher zu identifizieren die Verfahren ist vorgestellt mit eine große-schema-Datei.

Abgesehen davon, dass wir ordnen Sie ein Präfix ein, das die Funktion identifiziert.Wie

Proc_Poll_Interface, Proc_Inv_Interface etc.

Dies ermöglicht es uns, um alle gespeicherten Prozeduren, die nicht den job von POLL vs das tut, Inventar etc.

Jedenfalls ist die Präfix-Systems, hängt von Ihrem problem domain.Aber die al-gesagt und getan ist etwas ähnliches sollte vorhanden sein auch wenn es nur um Leuten zu erlauben, quicly suchen Sie die gespeicherte Prozedur in der explorere drop-down für die Bearbeitung.

anderen wie zB die Funktion.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Wir folgten der Funktion der Benennung coz Procs sind verwandt mit code / Funktion eher als statische Objekte wie Tabellen.Es wird nicht helfen, die Ausgelöst wird, könnte die Arbeit mit mehr als einer Tabelle.

Wenn der proc durchgeführt, mehr Funktionen, als behandelt werden können in einen einzelnen Namen, es heißt, Ihr proc tut so viel mehr als notwendig, seine Zeit, um Sie zu Spalten wieder.

Hoffe, das hilft.

Ich kam spät, um den Faden, aber ich möchte, dass meine Antwort hier eingeben:

In meinen letzten beiden Projekten gibt es unterschiedliche Trends wie, in dem wir verwendet:

Um Daten zu erhalten: s _G
  Um Daten zu löschen: s _D
  So fügen Sie Daten: s _I
  So aktualisieren Daten: s _U

Diese Namenskonventionen sind auch in Front-End, gefolgt von dem Wort prefixing 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 eine gute und einfache Namen zu erinnern.

Während in der zweiten Projekt haben wir die gleichen Namenskonventionen mit Lill Unterschied:

Um Daten zu erhalten: sp_ G
  So löschen Sie Daten: sp_ D
  So fügen Sie Daten: sp_ I
  So aktualisieren Daten: sp_ U

Beispiel:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow