Wat is uw naamgeving voor opgeslagen procedures?

Ik heb verschillende regels gezien voor het benoemen van opgeslagen procedures.

Sommige mensen voegen de sproc-naam vooraf met usp_, anderen met een afkorting voor de app-naam en weer anderen met de naam van de eigenaar. Je moet sp_ niet gebruiken in SQL Server, tenzij je het echt meent.

Sommigen beginnen de proc-naam met een werkwoord (Get, Add, Save, Remove). Anderen benadrukken de naam/namen van de entiteit.

In een database met honderden sprocs kan het erg moeilijk zijn om rond te scrollen en een geschikte sproc te vinden als je denkt dat er al een bestaat. Naamgevingsconventies kunnen het lokaliseren van een sproc gemakkelijker maken.

Gebruik je een naamgevingsconventie? Beschrijf het alstublieft en leg uit waarom u het verkiest boven andere keuzes.

Samenvatting van de antwoorden:

• Iedereen lijkt te pleiten voor consistentie in naamgeving, dat het misschien belangrijker is voor iedereen om dezelfde naamgevingsconventie te gebruiken dan welke specifieke wordt gebruikt.
• Voorvoegsels: terwijl veel mensen usp_ of iets dergelijks gebruiken (maar zelden sp_), gebruiken veel anderen de database- of app-naam. Eén slimme DBA gebruikt gen, rpt en tsk om algemene CRUD-sprocs te onderscheiden van die voor rapportage of taken.
• Werkwoord + zelfstandig naamwoord lijkt iets populairder te zijn dan zelfstandig naamwoord + werkwoord. Sommige mensen gebruiken de SQL-sleutelwoorden (Select, Insert, Update, Delete) voor de werkwoorden, terwijl anderen niet-SQL-werkwoorden (of afkortingen ervoor) gebruiken, zoals Get en Add. Sommigen maken onderscheid tussen enkelvoudige en meervoudige zelfstandige naamwoorden om aan te geven of een of meerdere records worden opgehaald.
• Waar van toepassing wordt aan het einde een extra zin voorgesteld. GetCustomerById, GetCustomerBySaleDate.
• Sommige mensen gebruiken underscores tussen de naamsegmenten en sommigen vermijden underscores. app_ Get_Customer vs. appGetCustomer — Ik denk dat het een kwestie van leesbaarheid is.
• Grote verzamelingen sprocs kunnen worden onderverdeeld in Oracle-pakketten of Management Studio (SQL Server)-oplossingen en -projecten, of SQL Server-schema’s.
• Ondoorgrondelijke afkortingen moeten worden vermeden.

Waarom ik voor het antwoord heb gekozen:er zijn ZOVEEL goede reacties. Bedankt iedereen! Zoals je kunt zien, zou het erg moeilijk zijn om er maar één te kiezen. Degene die ik koos resoneerde met mij. Ik heb hetzelfde pad gevolgd dat hij beschrijft – proberen werkwoord + zelfstandig naamwoord te gebruiken en vervolgens niet alle sprocs kunnen vinden die van toepassing zijn op de klant.

In staat zijn om een ​​bestaande sproc te lokaliseren, of te bepalen of er een bestaat, is erg belangrijk. Er kunnen ernstige problemen ontstaan ​​als iemand per ongeluk een dubbele sproc maakt met een andere naam.

Omdat ik over het algemeen aan zeer grote apps met honderden sprocs werk, heb ik een voorkeur voor de gemakkelijkst te vinden naamgevingsmethode. Voor een kleinere app zou ik kunnen pleiten voor Verb + Noun, omdat het de algemene codeerconventie voor methodenamen volgt.

Hij pleit ook voor het voorvoegsel van de app-naam in plaats van de niet erg nuttige usp_. Zoals verschillende mensen opmerkten, bevat de database soms sprocs voor meerdere apps. Dus een voorvoegsel met app-naam helpt om de sproc’s te scheiden EN helpt DBA’s en anderen om te bepalen voor welke app de sproc wordt gebruikt.

Antwoord 1, autoriteit 100%

Voor mijn laatste project heb ik usp_[Action][Object][Process] gebruikt, dus bijvoorbeeld usp_AddProduct of usp_GetProductList, usp_GetProductDetail. Maar nu de database op 700 procedures plus staat, wordt het een stuk moeilijker om alle procedures op een specifiek object te vinden. Ik moet nu bijvoorbeeld 50 oneven Add-procedures zoeken voor de Product-add, en 50 oneven voor Get etc.

Hierdoor ben ik van plan om in mijn nieuwe toepassing procedurenamen per object te groeperen, ik laat ook de usp vallen omdat ik vind dat het enigszins overbodig is, behalve om me te vertellen dat het een procedure is, iets waar ik van kan afleiden de naam van de procedure zelf.

Het nieuwe formaat is als volgt

[App]_[Object]_[Action][Process]
App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

Het helpt om dingen te groeperen zodat je ze later gemakkelijker kunt terugvinden, vooral als er een groot aantal sprocs is.

Wat betreft waar meer dan één object wordt gebruikt, vind ik dat de meeste instanties een primair en secundair object hebben, dus het primaire object wordt gebruikt in de normale instantie en naar het secundaire object wordt verwezen in de processectie, bijvoorbeeld App_Product_AddAttribute.

Antwoord 2, autoriteit 54%

Hier is wat verduidelijking over het sp_ prefix-probleem in SQL Server.

Opgeslagen procedures met het voorvoegsel sp_ zijn systeem-sproc’s die zijn opgeslagen in de hoofddatabase.

Als je je sproc dit voorvoegsel geeft, zoekt SQL Server ze eerst in de hoofddatabase en daarna in de contextdatabase, waardoor onnodige bronnen worden verspild. En als de door de gebruiker gemaakte sproc dezelfde naam heeft als een systeem-sproc, wordt de door de gebruiker gemaakte sproc niet uitgevoerd.

Het sp_ voorvoegsel geeft aan dat de sproc toegankelijk is vanuit alle databases, maar dat het moet worden uitgevoerd in de context van de huidige database.

Hier iseen mooie uitleg, inclusief een demo van de uitvoering raak.

Hier isnog een nuttige bron van Ant in een commentaar.

Antwoord 3, autoriteit 24%

Systems Hongaars(zoals het bovenstaande “usp”-voorvoegsel) doet me huiveren.

We delen veel opgeslagen procedures over verschillende databases met dezelfde structuur, dus voor databasespecifieke gebruiken we een voorvoegsel van de databasenaam zelf; gedeelde procedures hebben geen voorvoegsel. Ik veronderstel dat het gebruik van verschillende schema’s een alternatief zou kunnen zijn om van zulke lelijke voorvoegsels af te komen.

De werkelijke naam achter het voorvoegsel verschilt nauwelijks van functiebenoeming: typisch een werkwoord als “Toevoegen”, “Instellen”, “Genereren”, “Berekenen”, “Verwijderen”, enz., gevolgd door een aantal meer specifieke zelfstandige naamwoorden zoals als “Gebruiker”, “Dagelijkse inkomsten”, enzovoort.

Reageren op de opmerking van Ant:

1. Het verschil tussen een tabel en een weergave is relevant voor degenen die het databaseschema ontwerpen, niet voor degenen die de inhoud openen of wijzigen. In het zeldzame geval dat u schemaspecificaties nodig heeft, is het gemakkelijk genoeg te vinden. Voor de gewone SELECT-query is het niet relevant. In feite beschouw ik het als een groot voordeel om tabellen en views hetzelfde te kunnen behandelen.
2. In tegenstelling tot functies en opgeslagen procedures, is het onwaarschijnlijk dat de naam van een tabel of weergave met een werkwoord begint, of iets anders is dan een of meer zelfstandige naamwoorden.
3. Voor een functie moet het schemaprefix worden aangeroepen. In feite is de aanroepsyntaxis (die we sowieso gebruiken) heel anders tussen een functie en een opgeslagen procedure. Maar zelfs als dat niet zo was, zou hetzelfde als 1. gelden: als ik functies en opgeslagen procedures hetzelfde kan behandelen, waarom zou ik dat dan niet doen?

Antwoord 4, autoriteit 16%

TableName_WhatItDoes

• Comment_GetByID

• Klantenlijst

• UserPreference_DeleteByUserID

Geen voorvoegsels of domme Hongaarse onzin. Alleen de naam van de tabel waarmee het het meest geassocieerd is, en een korte beschrijving van wat het doet.

Een waarschuwing bij het bovenstaande: ik plaats persoonlijk altijd al mijn automatisch gegenereerde CRUD’s met zCRUD_ zodat deze aan het einde van de lijst worden gesorteerd, waar ik er niet naar hoef te kijken.

Antwoord 5, autoriteit 15%

Ik heb in de loop der jaren vrijwel alle verschillende systemen gebruikt. Ik heb eindelijk deze ontwikkeld, die ik nog steeds gebruik:

Voorvoegsel:

• gen – Algemeen: CRUD, meestal
• rpt – Rapport: spreekt voor zich
• tsk – Taak: meestal iets met procedurele logica, uitgevoerd via geplande taken

Actiespecificatie:

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

(In gevallen waarin de procedure veel dingen doet, wordt het algemene doel gebruikt om de actiespecificatie te kiezen. Een klant INSERT kan bijvoorbeeld veel voorbereidend werk vergen, maar het algemene doel is INSERT, dus “Ins” is gekozen.

Object:

Voor gen (CRUD) is dit de tabel- of weergavenaam die wordt beïnvloed. Voor rpt (Report) is dit de korte beschrijving van het rapport. Voor tsk (Taak) is dit de korte beschrijving van de taak.

Optionele verduidelijkers:

Dit zijn optionele stukjes informatie die worden gebruikt om het begrip van de procedure te vergroten. Voorbeelden zijn “Door”, “Voor”, enz.

Formaat:

[Voorvoegsel][Actiespecificatie][Entiteit][Optionele verduidelijkingen]

Voorbeelden van procedurenamen:

genInsOrderHeader
genSelCustomerByCustomerID
genSelCustomersBySaleDate
genUpdCommentText
genDelOrderDetailLine
rptSelCustomersByState
rptSelPaymentsByYear
tskQueueAccountsForCollection

Antwoord 6, autoriteit 15%

Het starten van een opgeslagen procedurenaam met sp_is slecht in SQL Server omdat de systeem-sproc’s allemaal beginnen met sp_. Consistente naamgeving (zelfs in de mate van kobolddom) is nuttig omdat het geautomatiseerde taken op basis van de datadictionary mogelijk maakt. Voorvoegsels zijn iets minder handig in SQL Server 2005 omdat het schema’s ondersteunt, die voor verschillende soorten naamruimten kunnen worden gebruikt op de manier waarop voorvoegsels op namen vroeger werden gebruikt. Op een sterschema zou men bijvoorbeeld de schema’s dimen factkunnen hebben en volgens deze conventie naar tabellen kunnen verwijzen.

Voor opgeslagen procedures is het voorvoegsel nuttig om applicatie-sprocs te identificeren van systeem-sprocs. up_vs. sp_maakt het relatief eenvoudig om niet door het systeem opgeslagen procedures uit de datadictionary te identificeren.

Antwoord 7, autoriteit 7%

voor kleine databases gebruik ik uspTableNameOperationName, b.v. uspCustomerCreate, uspCustomerDelete, etc. Dit vergemakkelijkt het groeperen op ‘hoofd’ entiteit.

voeg voor grotere databases een schema of subsysteemnaam toe, b.v. Ontvangen, kopen, enz. om ze gegroepeerd te houden (aangezien de sql-server ze graag alfabetisch weergeeft)

ik probeer afkortingen in de namen te vermijden, voor de duidelijkheid (en nieuwe mensen in het project hoeven zich niet af te vragen waar ‘UNAICFE’ voor staat omdat de sproc uspUsingNoAbbreviationsIncreasesClarityForEveryone heet)

Antwoord 8, autoriteit 6%

Ik kapselt de opgeslagen procedures altijd in pakkettenin (ik gebruik Oracle op mijn werk). Dat vermindert het aantal afzonderlijke objecten en helpt bij het hergebruik van code.

De naamgevingsconventie is een kwestie van smaak en je moet het bij de start van het project met alle andere ontwikkelaars eens zijn.

Antwoord 9, autoriteit 6%

Ik gebruik momenteel een indeling die er als volgt uitziet

Notatie:

[PREFIX][APPLICATIE][MODULE]_[NAAM]

Voorbeeld:

P_CMS_USER_UserInfoGet

Ik hou van deze notatie om een ​​paar redenen:

• door te beginnen met een heel eenvoudig voorvoegsel kan code worden geschreven om alleen objecten uit te voeren die beginnen met het voorvoegsel (om bijvoorbeeld SQL-injectie te verminderen)
• in onze grotere omgeving werken meerdere teams aan verschillende apps die op dezelfde database-architectuur draaien. De Applicatie-notatie geeft aan welke groep eigenaar is van de SP.
• De secties Module en Naam maken de hiërarchie gewoon compleet. Alle namen moeten kunnen worden gekoppeld aan Groep/App, Module, Functie uit de hiërarchie.

Antwoord 10, autoriteit 3%

Ik gebruik altijd:

usp[Tabelnaam][Actie][Extra details]

Gegeven een tabel met de naam “tblUser”, die me geeft:

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

De procedures zijn alfabetisch gesorteerd op tabelnaam en op functionaliteit, dus het is gemakkelijk te zien wat ik met een bepaalde tabel kan doen. Door het voorvoegsel “usp” te gebruiken, weet ik wat ik roep als ik (bijvoorbeeld) een procedure van 1000 regels schrijf die interageert met andere procedures, meerdere tabellen, functies, views en servers.

Totdat de editor in de SQL Server IDE zo goed is als Visual Studio, bewaar ik de voorvoegsels.

Antwoord 11, autoriteit 3%

application prefix_ operations prefix_ beschrijving van betrokken database-objecten (minus de spaties tussen underscores – moest spaties invoegen om ze te laten verschijnen).

bewerkingsvoorvoegsels die we gebruiken –

• “get” – retourneert een recordset
• “ins” – voegt gegevens in
• “upd” – werkt gegevens bij
• “del” – verwijdert gegevens

bijv.

wmt_ ins _ klantgegevens

“tool voor personeelsbeheer, voeg details toe aan de klantentabel”

voordelen

Alle opgeslagen procedures die betrekking hebben op dezelfde toepassing zijn gegroepeerd op naam. Binnen de groep worden opgeslagen procedures die dezelfde soort bewerking uitvoeren (bijv. invoegingen, updates, enz.) gegroepeerd.

Dit systeem werkt goed voor ons, met ca. 1000 opgeslagen procedures in één database uit mijn hoofd.

Tot nu toe nog geen nadelen van deze aanpak tegengekomen.

Antwoord 12, autoriteit 3%

GetXXX – Krijgt XXX op basis van @ID

GetAllXXX – Krijgt alle XXX

PutXXX – Voegt XXX in indien doorgegeven @ID is -1; anders updates

DelXXX – Verwijdert XXX op basis van @ID

Antwoord 13

Ik denk dat de usp_-naamgevingsconventie niemand goed doet.

In het verleden heb ik Get/Update/Insert/Delete prefixen gebruikt voor CRUD-bewerkingen, maar sinds ik Linq to SQL of de EF gebruik om het meeste van mijn CRUD-werk te doen, zijn deze volledig verdwenen. Omdat ik zo weinig procs heb opgeslagen in mijn nieuwe applicaties, doen de naamgevingsconventies er niet meer toe zoals vroeger 😉

Antwoord 14

Voor de huidige toepassing waaraan ik werk, hebben we een voorvoegsel dat de naam van de toepassing identificeert (vier kleine letters). De reden hiervoor is dat onze applicatie naast een legacy applicatie in dezelfde database moet kunnen bestaan, dus het voorvoegsel is een must.

Als we de legacy-beperking niet hadden, ben ik er vrij zeker van dat we geen prefix zouden gebruiken.

Na het voorvoegsel beginnen we de SP-naam meestal met een werkwoord dat beschrijft wat de procedure doet, en vervolgens de naam van de entiteit waarop we werken. Pluralisatie van de naam van de entiteit is toegestaan ​​- We proberen de leesbaarheid te benadrukken, zodat het duidelijk is wat de procedure doet uit de naam alleen.

Typische namen van opgeslagen procedures in ons team zijn:

shopGetCategories
shopUpdateItem

Antwoord 15

Ik denk niet dat het er echt toe doet wat je prefix precies is, zolang je maar logisch en consistent bent. Persoonlijk gebruik ik

spu_[actiebeschrijving][procesbeschrijving]

waarbij de actiebeschrijving een van een klein aantal typische acties is, zoals ophalen, instellen, archiveren, invoegen, verwijderen enz. De procesbeschrijving is bijvoorbeeld kort maar beschrijvend

spu_archiveCollectionData

of

spu_setAwardStatus

Ik noem mijn functies op dezelfde manier, maar prefix met udf_

Ik heb mensen zien proberen pseudo-Hongaarse notatie te gebruiken voor het benoemen van procedures, wat naar mijn mening meer verbergt dan het onthult. Zolang ik mijn procedures alfabetisch opsom, kan ik ze gegroepeerd zien op functionaliteit, dan lijkt dat voor mij de goede plek tussen orde en onnodige nauwkeurigheid

Antwoord 16

Vermijd sp_* in SQl-server, want alle door het systeem opgeslagen procedures beginnen met sp_ en daarom wordt het moeilijker voor het systeem om het object te vinden dat overeenkomt met de naam.

Dus als je met iets anders dan sp_ begint, wordt het makkelijker.

Dus we gebruiken om te beginnen een algemene naam voor Proc_. Dat maakt het gemakkelijker om de procedures te identificeren als ze worden gepresenteerd met één groot schemabestand.

Daarnaast kennen we een voorvoegsel toe dat de functie identificeert. Vind ik leuk

Proc_Poll_Interface, Proc_Inv_Interfaceenz.

Hierdoor kunnen we alle opgeslagen processen vinden die het werk van POLL doen versus die van inventaris enz.

Hoe dan ook, het prefix-systeem hangt af van uw probleemdomein. Maar al wat gezegd en gedaan had, zou iets soortgelijks aanwezig moeten zijn, al was het maar om mensen in staat te stellen de opgeslagen procedure snel te lokaliseren in de vervolgkeuzelijst van de verkenner om te bewerken.

andere bv’s van functie.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

We hebben de functie-gebaseerde naamgeving gevolgd, omdat Procs verwant zijn aan code / functie in plaats van statische objecten zoals tabellen. Het helpt niet dat Procs met meer dan één tabel zou kunnen werken.

Als de proc meer functies heeft uitgevoerd dan in één naam kunnen worden afgehandeld, betekent dit dat uw proc veel meer doet dan nodig is en dat het tijd is om ze opnieuw te splitsen.

Hopelijk helpt dat.

Antwoord 17

Ik heb me laat in de discussie gevoegd, maar ik wil hier mijn antwoord invoeren:

In mijn laatste twee projecten zijn er verschillende trends, zoals in één die we gebruikten:

Gegevens ophalen: s<tabelnaam>_G
Gegevens verwijderen: s<tabelnaam>_D
Gegevens invoegen: s<tabelnaam>_I
Gegevens bijwerken: s<tabelnaam>_U

Deze naamgevingsconventies worden in de front-end ook gevolgd door het woord dtvoor te voegen.

Voorbeeld:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

Met behulp van bovenstaande naamgevingsconventies in onze applicatie hebben we een goede en gemakkelijk te onthouden namen.

Terwijl we in het tweede project dezelfde naamgevingsconventies gebruikten met weinig verschil:

Gegevens ophalen: sp_<tabelnaam>G
Gegevens verwijderen: sp_<tabelnaam>D
Gegevens invoegen: sp_<tabelnaam>I
Gegevens bijwerken: sp_<tabelnaam>U

Voorbeeld:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU