Qual è la tua convenzione di denominazione per le stored procedure? [chiuso]

Ho visto varie regole per la denominazione di stored procedure.

Alcune persone precedono il nome sproc con usp_, altre con un'abbreviazione per il nome dell'app e altre ancora con il nome del proprietario. Non dovresti usare sp_ in SQL Server a meno che tu non lo pensi davvero.

Alcuni iniziano il nome del proc con un verbo (Get, Add, Save, Remove). Altri enfatizzano i nomi delle entità.

Su un database con centinaia di sproc, può essere molto difficile scorrere e trovare uno sproc adatto quando pensi che ne esista già uno. Le convenzioni di denominazione possono semplificare l'individuazione di uno sproc.

Usi una convenzione di denominazione? Descrivilo e spiega perché lo preferisci rispetto ad altre scelte.

Riepilogo delle risposte:

• Tutti sembrano sostenere la coerenza della denominazione, che potrebbe essere più importante per tutti utilizzare la stessa convenzione di denominazione di quella in particolare utilizzata.
• Prefissi: mentre molte persone usano usp_ o qualcosa di simile (ma raramente sp_), molti altri usano il database o il nome dell'app. Un DBA intelligente utilizza gen, rpt e tsk per distinguere gli sprocs CRUD generali da quelli utilizzati per il reporting o le attività.
• Verbo + Sostantivo sembra essere leggermente più popolare di Sostantivo + Verbo. Alcune persone usano le parole chiave SQL (Seleziona, Inserisci, Aggiorna, Elimina) per i verbi, mentre altri usano verbi non SQL (o abbreviazioni per essi) come Ottieni e Aggiungi. Alcuni distinguono tra sostantivi singluari e plurali per indicare se si stanno recuperando uno o più record.
• Una frase aggiuntiva è suggerita alla fine, se del caso. GetCustomerById, GetCustomerBySaleDate.
• Alcune persone usano trattini bassi tra i segmenti del nome e altri evitano i trattini bassi. app_ Get_Customer vs. appGetCustomer: immagino sia una questione di leggibilità.
• Grandi raccolte di sproc possono essere separate in pacchetti Oracle o soluzioni e progetti Management Studio (SQL Server) o schemi SQL Server.
• Le abbreviazioni imperscrutabili dovrebbero essere evitate.

Perché ho scelto la risposta che ho fatto: ci sono così tante buone risposte. Grazie a tutti! Come puoi vedere, sarebbe molto difficile sceglierne solo uno. Quello che ho scelto ha risuonato con me. Ho seguito lo stesso percorso che descrive: cercando di utilizzare Verbo + Sostantivo e poi non sono riuscito a trovare tutti gli sproc che si applicano al Cliente.

Essere in grado di localizzare uno sproc esistente, o di determinare se ne esiste uno, è molto importante. Possono sorgere problemi seri se qualcuno crea inavvertitamente uno sproc duplicato con un altro nome.

Dato che generalmente lavoro su app molto grandi con centinaia di sproc, prediligo il metodo di denominazione più facile da trovare. Per un'app più piccola, potrei consigliare Verbo + Sostantivo, poiché segue la convenzione di codifica generale per i nomi dei metodi.

Inoltre, sostiene il prefisso con il nome dell'app invece del non molto utile usp_. Come hanno sottolineato diverse persone, a volte il database contiene sproc per più app. Quindi, il prefisso con il nome dell'app aiuta a separare gli sproc E aiuta gli amministratori di database e altri a determinare per quale app viene utilizzato lo sproc.

Per il mio ultimo progetto ho usato usp_ [Action] [Object] [Process] quindi, ad esempio, usp_AddProduct o usp_GetProductList, usp_GetProductDetail. Tuttavia ora il database è a 700 procedure e in più, diventa molto più difficile trovare tutte le procedure su un oggetto specifico. Ad esempio, ora devo cercare 50 procedure di aggiunta dispari per l'aggiunta del prodotto e 50 dispari per il Get ecc.

Per questo motivo nella mia nuova applicazione sto pianificando di raggruppare i nomi delle procedure per oggetto, sto anche eliminando l'usp poiché ritengo che sia in qualche modo ridondante, oltre a dirmi che è una procedura, qualcosa che posso dedurre dal nome di la procedura stessa.

Il nuovo formato è il seguente

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

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

Aiuta a raggruppare le cose per trovarle più facilmente in seguito, soprattutto se ci sono una grande quantità di prodotti.

Per quanto riguarda dove viene utilizzato più di un oggetto, trovo che la maggior parte delle istanze abbia un oggetto primario e secondario, quindi l'oggetto primario viene utilizzato nell'istanza normale e il secondario è indicato nella sezione del processo, ad esempio App_Product_AddAttribute.

Di seguito sono riportati alcuni chiarimenti sul problema del prefisso sp_ in SQL Server.

Le stored procedure denominate con il prefisso sp_ sono sproc di sistema archiviate nel database master.

Se si assegna a sproc questo prefisso, SQL Server li cerca prima nel database Master, quindi nel database di contesto, sprecando così inutilmente risorse. E, se lo sproc creato dall'utente ha lo stesso nome di uno sproc di sistema, lo sproc creato dall'utente non verrà eseguito.

Il prefisso sp_ indica che sproc è accessibile da tutti i database, ma che dovrebbe essere eseguito nel contesto del database corrente.

Ecco una bella spiegazione, che include una demo del successo.

Ecco un'altra fonte utile fornita da Ant in un commento.

I sistemi ungheresi (come il prefisso "usp" sopra) mi fanno rabbrividire.

Condividiamo molte procedure memorizzate tra database diversi e strutturati in modo simile, quindi per quelli specifici del database, utilizziamo un prefisso del nome del database stesso; le procedure condivise non hanno prefisso. Suppongo che l'uso di schemi diversi potrebbe essere un'alternativa per sbarazzarsi del tutto di prefissi così brutti.

Il nome effettivo dopo il prefisso non è molto diverso dalla denominazione della funzione: in genere un verbo come "Aggiungi", "Imposta", "Genera", "Calcola", "Elimina", ecc., Seguito da molti nomi più specifici come "Utente "," DailyRevreed "e così via.

Rispondendo al commento di Ant:

1. La differenza tra una tabella e una vista è rilevante per coloro che progettano lo schema del database, non per coloro che accedono o modificano il suo contenuto. Nel raro caso in cui siano necessarie specifiche dello schema, è abbastanza facile da trovare. Per la query SELECT casuale, è irrilevante. In effetti, considero la possibilità di trattare tabelle e visualizzazioni allo stesso modo un grande vantaggio.
2. A differenza delle funzioni e delle stored procedure, è improbabile che il nome di una tabella o di una vista inizi con un verbo o sia qualcosa di diverso da uno o più nomi.
3. Una funzione richiede la chiamata del prefisso dello schema. In effetti, la sintassi della chiamata (che usiamo comunque) è molto diversa tra una funzione e una procedura memorizzata. Ma anche se non lo fosse, si applicherebbe lo stesso di 1.: se posso trattare le funzioni e le stored procedure allo stesso modo, perché non dovrei?

Ho utilizzato praticamente tutti i diversi sistemi nel corso degli anni. Alla fine ho sviluppato questo, che continuo a usare oggi:

Prefisso:

• gen - Generale: CRUD, principalmente
• rpt - Report: autoesplicativo
• tsk - Attività: di solito qualcosa con logica procedurale, eseguita tramite processi pianificati

Identificatore di azione:

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

(Nei casi in cui la procedura fa molte cose, l'obiettivo generale viene utilizzato per scegliere l'identificatore dell'azione. Ad esempio, un INSERT del cliente può richiedere una buona quantità di lavoro di preparazione, ma l'obiettivo generale è INSERT, quindi viene scelto "Ins".

Oggetto:

Per gen (CRUD), questo è il nome della tabella o della vista interessato. Per rpt (Report), questa è la breve descrizione del report. Per tsk (Task) questa è la breve descrizione dell'attività.

Chiarificatori opzionali:

Si tratta di bit di informazioni opzionali utilizzati per migliorare la comprensione della procedura. Gli esempi includono "Di", "Per" e così via.

Formato:

[Prefisso] [Identificatore azione] [Entità] [Chiarificatori facoltativi]

Esempi di nomi di procedura:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

TableName_WhatItDoes

• Comment_GetByID

• Customer_List

• UserPreference_DeleteByUserID

Nessun prefisso o sciocchezze ungheresi. Solo il nome della tabella a cui è più strettamente associata e una breve descrizione di ciò che fa.

Un avvertimento a quanto sopra: personalmente ho sempre anteposto a tutti i miei CRUD autogenerati zCRUD_ in modo che si ordina alla fine della lista dove non devo guardarlo.

L'avvio di un nome di stored procedure con non sp_è valido in SQL Server perché tutti gli sproc di sistema iniziano con sp_. La denominazione coerente (anche nella misura di hobgoblin-dom) è utile perché facilita le attività automatizzate basate sul dizionario dei dati. I prefissi sono leggermente meno utili in SQL Server 2005 in quanto supporta gli schemi, che possono essere utilizzati per vari tipi di spazi dei nomi nel modo in cui i prefissi sui nomi erano soliti. Ad esempio, su uno schema a stella, si potrebbero avere schemi oscuri e fatti e fare riferimento a tabelle secondo questa convenzione.

Per le stored procedure, il prefisso è utile allo scopo di identificare gli sproc delle applicazioni dagli sproc di sistema. up_vs. sp_rende relativamente facile identificare le stored procedure non di sistema dal dizionario dei dati.

Incapsulo sempre le stored procedure in pacchetti (sto usando Oracle, al lavoro). Ciò ridurrà il numero di oggetti separati e aiuterà il riutilizzo del codice.

La convenzione di denominazione è una questione di gusti e qualcosa che dovresti essere d'accordo con tutti gli altri sviluppatori all'inizio del progetto.

per i database di piccole dimensioni, utilizzo uspTableNameOperationName, ad esempio uspCustomerCreate, uspCustomerDelete, ecc. Ciò facilita il raggruppamento per entità "principale".

per database più grandi, aggiungi uno schema o un nome di sottosistema, ad esempio Ricezione, Acquisti, ecc. per mantenerli raggruppati (poiché al server SQL piace visualizzarli in ordine alfabetico)

cerco di evitare le abbreviazioni nei nomi, per chiarezza (e le nuove persone nel progetto non devono chiedersi cosa significhi 'UNAICFE' perché lo sproc si chiama uspUsingNoAbbreviationsIncreasesClarityForEveryone)

Attualmente utilizzo un formato simile al seguente

Notazione:

[PREFISSO] [APPLICAZIONE] [MODULO] _ [NOME]

Esempio:

P_CMS_USER_UserInfoGet

Mi piace questa notazione per alcuni motivi:

• iniziare con un prefisso molto semplice consente di scrivere codice per eseguire solo oggetti che iniziano con il prefisso (per ridurre l'iniezione SQL, ad esempio)
• nel nostro ambiente più ampio, più team lavorano su app diverse che funzionano con la stessa architettura di database. La notazione dell'applicazione indica quale gruppo possiede l'SP.
• Le sezioni Modulo e Nome completano semplicemente la gerarchia. Tutti i nomi dovrebbero poter essere abbinati a Gruppo / App, Modulo, Funzione dalla gerarchia.

Uso sempre:

usp [Nome tabella] [Azione] [Dettagli extra]

Data una tabella chiamata "tblUser", che mi dà:

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

Le procedure sono ordinate alfabeticamente in base al nome della tabella e alla funzionalità, quindi è facile vedere cosa posso fare con una determinata tabella. L'utilizzo del prefisso "usp" mi consente di sapere cosa sto chiamando se (ad esempio) sto scrivendo una procedura di 1000 righe che interagisce con altre procedure, più tabelle, funzioni, viste e server.

Fino a quando l'editor nell'IDE di SQL Server non è buono come Visual Studio, manterrò i prefissi.

prefisso applicazione_ prefisso operazione_ descrizione degli oggetti del database coinvolti (meno gli spazi tra i caratteri di sottolineatura - è stato necessario inserire degli spazi per farli apparire) .

prefissi di operazioni che usiamo -

• " Get " - restituisce un recordset
• " Ins " - inserisce i dati
• " Upd " - aggiorna i dati
• " Del ": elimina i dati

per esempio

wmt_ ins _ customer _details

"strumento di gestione della forza lavoro, inserisci i dettagli nella tabella dei clienti"

vantaggi

Tutte le stored procedure relative alla stessa applicazione vengono raggruppate per nome. All'interno del gruppo sono raggruppate le stored procedure che eseguono lo stesso tipo di operazione (es. Inserimenti, aggiornamenti, ecc.).

Questo sistema funziona bene per noi, avendo ca. 1000 stored procedure in un database dalla parte superiore della mia testa.

Finora non ho riscontrato svantaggi in questo approccio.

GetXXX: ottiene XXX in base a @ID

GetAllXXX - Ottiene tutti i XXX

PutXXX - Inserisce XXX se passato @ID è -1; altro aggiornamenti

DelXXX: elimina XXX in base a @ID

Penso che la convenzione di denominazione usp_ non faccia bene a nessuno.

In passato, ho usato i prefissi Get / Update / Insert / Delete per le operazioni CRUD, ma ora che uso Linq to SQL o EF per fare la maggior parte del mio lavoro CRUD, questi sono completamente spariti. Dato che ho così pochi proc memorizzati nelle mie nuove applicazioni, le convenzioni di denominazione non contano più come una volta ;-)

Per l'applicazione corrente su cui sto lavorando, abbiamo un prefisso che identifica il nome dell'applicazione (quattro lettere minuscole). La ragione di ciò è che la nostra applicazione deve essere in grado di coesistere con un'applicazione legacy nello stesso database, quindi il prefisso è un must.

Se non avessimo il vincolo legacy, sono abbastanza sicuro che non avremmo utilizzato un prefisso.

Dopo il prefisso di solito iniziamo il nome SP con un verbo che descrive cosa fa la procedura, e poi il nome dell'entità su cui operiamo. È consentito il pluralismo del nome dell'entità - Cerchiamo di enfatizzare la leggibilità, in modo che sia ovvio cosa fa la procedura dal solo nome.

I nomi tipici delle stored procedure nel nostro team sarebbero:

shopGetCategories
shopUpdateItem

Non penso che importi davvero esattamente quale sia il tuo prefisso fintanto che sei logico e coerente. Personalmente lo uso

spu_ [descrizione dell'azione] [descrizione del processo]

dove la descrizione dell'azione è una piccola gamma di azioni tipiche come ottenere, impostare, archiviare, inserire, eliminare ecc. La descrizione del processo è qualcosa di breve ma descrittivo, per esempio

spu_archiveCollectionData 

o

spu_setAwardStatus

Nomino le mie funzioni in modo simile, ma il prefisso è udf_

Ho visto persone tentare di utilizzare la notazione pseudo-ungherese per la denominazione delle procedure, che a mio parere nasconde più di quanto rivela. Finché quando elenco le mie procedure in ordine alfabetico posso vederle raggruppate per funzionalità, per me questo sembra essere il punto debole tra ordine e rigore non necessario

Evitare sp_ * nel server SQl perché tutte le procedure memorizzate di sistema iniziano con sp_ e quindi diventa più difficile per il sistema trovare l'oggetto corrispondente al nome.

Quindi se inizi con qualcosa di diverso da sp_ le cose diventano più facili.

Quindi usiamo una denominazione comune di Proc_ per cominciare. Ciò semplifica l'identificazione delle procedure se presentate con un unico grande file di schema.

A parte questo, assegniamo un prefisso che identifica la funzione. Piace

Proc_Poll_Interface, Proc_Inv_Interface eccetera.

Questo ci consente di trovare tutti i processi memorizzati che fanno il lavoro di POLL rispetto a quello di Inventory, ecc.

In ogni caso il sistema dei prefissi dipende dal tuo dominio problematico. Ma tutto ciò che è stato detto e fatto dovrebbe essere presente anche se è solo per consentire alle persone di individuare rapidamente la procedura memorizzata nel menu a discesa Explorer per la modifica.

altri eg di funzione.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Abbiamo seguito la denominazione basata sulla funzione perché i Procs sono simili a codice / funzione piuttosto che a oggetti statici come le tabelle. Non aiuta il fatto che Procs possa funzionare con più di una tabella.

Se il proc ha eseguito più funzioni di quelle che possono essere gestite con un solo nome, significa che il tuo proc sta facendo molto più del necessario ed è ora di dividerle di nuovo.

Spero che aiuti.

Sono entrato in ritardo nel thread ma voglio inserire la mia risposta qui:

Nei miei ultimi due progetti ci sono tendenze diverse come, in uno abbiamo usato:

Per ottenere i dati: s <tablename> _G
Per eliminare i dati: s <tablename> _D
Per inserire i dati: s <tablename> _I
Per aggiornare i dati: s <tablename> _U

Queste convenzioni di denominazione sono seguite anche nel front-end anteponendo la parola dt .

Esempio:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

Con l'aiuto delle convenzioni di denominazione di cui sopra nella nostra applicazione, abbiamo nomi buoni e facili da ricordare.

Mentre nel secondo progetto abbiamo usato le stesse convenzioni di denominazione con lill differenza:

Per ottenere i dati: sp_ <tablename> G
Per eliminare i dati: sp_ <tablename> D
Per inserire i dati: sp_ <tablename> I
Per aggiornare i dati: sp_ <tablename> U

Esempio:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU