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

StackOverflow https://stackoverflow.com/questions/238267

Domanda

Ho visto varie regole per nominare le stored procedure.

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

Alcuni iniziano il nome proc con un verbo (Ottieni, Aggiungi, Salva, Rimuovi). Altri sottolineano i nomi delle entità.

Su un database con centinaia di sprocs, 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 usare la stessa convenzione di denominazione di quella usata in particolare.
  • Prefissi: mentre molte persone usano usp_ o qualcosa di simile (ma raramente sp_), molti altri usano il nome del database o dell'app. Un DBA intelligente utilizza gen, rpt e tsk per distinguere gli sprocs CRUD generali da quelli utilizzati per i report o le attività.
  • Verbo + Noun sembra essere leggermente più popolare di Noun + Verbo. Alcune persone usano le parole chiave SQL (Seleziona, Inserisci, Aggiorna, Elimina) per i verbi, mentre altri usano verbi non SQL (o abbreviazioni per loro) come Ottieni e Aggiungi. Alcuni distinguono tra nomi singolari e plurali per indicare se uno o più record sono stati recuperati.
  • Alla fine viene suggerita una frase aggiuntiva, ove appropriato. GetCustomerById, GetCustomerBySaleDate.
  • Alcune persone usano i caratteri di sottolineatura tra i segmenti di nome e altri lo evitano. 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 di Management Studio (SQL Server) o schemi di SQL Server.
  • Abbreviazioni imperscrutabili dovrebbero essere evitate.

Perché scelgo 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 risuona con me. Ho seguito lo stesso percorso che descrive - cercando di usare Verb + Noun e quindi non essere in grado di trovare tutti gli sproc che si applicano al Cliente.

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

Dato che generalmente lavoro su app di grandi dimensioni con centinaia di sprocs, preferisco il metodo di denominazione più facile da trovare. Per un'app più piccola, potrei sostenere Verb + Noun, poiché segue la convenzione di codifica generale per i nomi dei metodi.

Suggerisce inoltre il prefisso con il nome dell'app anziché l'usp_ non molto utile. Come diverse persone hanno sottolineato, a volte il database contiene sprocs per più app. Pertanto, il prefisso con il nome dell'app aiuta a separare gli sproc e aiuta i DBA e altri a determinare per quale app viene utilizzato lo sproc.

È stato utile?

Soluzione

Per il mio ultimo progetto ho usato usp_ [Action] [Object] [Process], ad esempio usp_AddProduct o usp_GetProductList, usp_GetProductDetail. Tuttavia ora il database è a 700 procedure 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 ottenere ecc.

A causa di ciò, nella mia nuova applicazione, sto pianificando di raggruppare i nomi delle procedure per oggetto, sto anche lasciando cadere l'USP poiché ritengo che sia in qualche modo ridondante, oltre a dirmi che è una procedura, qualcosa da cui posso dedurre il nome della 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 una più facile ricerca in seguito, specialmente se ci sono molti sprocs.

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

Altri suggerimenti

Ecco alcuni chiarimenti sul problema del prefisso sp_ in SQL Server.

Le stored procedure denominate con il prefisso sp_ sono sprocs di sistema archiviati nel database Master.

Se dai questo prefisso al tuo sproc, SQL Server li cerca prima nel database Master, quindi nel database di contesto, sprecando 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 lo sproc è accessibile da tutti i database, ma che dovrebbe essere eseguito nel contesto del database corrente.

Ecco una bella spiegazione, che include una demo della performance colpito.

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

Sistemi ungheresi (come il precedente " usp " ; prefisso) mi fa rabbrividire.

Condividiamo molte procedure memorizzate su diversi database 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 di tali brutti prefissi del tutto.

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

Risposta 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 di necessità di specifiche dello schema, è abbastanza facile da trovare. Per la query SELECT casuale, è irrilevante. In effetti, considero la possibilità di trattare tabelle e viste come un grande vantaggio.
  2. A differenza delle funzioni e delle stored procedure, è improbabile che il nome di una tabella o vista inizi con un verbo o sia tutt'altro che uno o più nomi.
  3. Una funzione richiede il richiamo 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 potessi trattare le funzioni e le stored procedure allo stesso modo, perché non dovrei?

L'avvio di un nome di procedura memorizzata con sp_ non è corretto in SQL Server poiché tutti gli sprocs 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 poiché supportano gli schemi, che possono essere utilizzati per vari tipi di spazi dei nomi nel modo in cui erano usati i prefissi sui nomi. Ad esempio, su uno schema a stella, si potrebbero avere schemi dim e fact e fare riferimento alle tabelle di questa convenzione.

Per le stored procedure, il prefisso è utile allo scopo di identificare gli sprocs delle applicazioni dagli sprocs di sistema. up_ vs. <=> semplifica l'identificazione delle procedure memorizzate non di sistema dal dizionario dei dati.

TableName_WhatItDoes

  • Comment_GetByID

  • Customer_List

  • UserPreference_DeleteByUserID

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

Un avvertimento a quanto sopra: ho personalmente sempre il prefisso di tutti i miei CRUD generati automaticamente con zCRUD_ in modo che si classifichi alla fine dell'elenco dove non devo guardarli.

Ho usato praticamente tutti i diversi sistemi nel corso degli anni. Finalmente ho sviluppato questo, che continuo ad usare oggi:

Prefisso:

  • gen - Generale: CRUD, principalmente
  • rpt - Rapporto: autoesplicativo
  • tsk - Compito: solitamente qualcosa con logica procedurale, eseguito tramite lavori programmati

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 di azione. Ad esempio, un cliente INSERT può richiedere un buon lavoro di preparazione, ma l'obiettivo generale è INSERT, quindi " Ins " è stato scelto.

Oggetto:

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

Chiarificatori opzionali:

Queste sono informazioni facoltative utilizzate per migliorare la comprensione della procedura. Gli esempi includono & Quot; By & Quot ;, & Quot; Per & Quot ;, ecc.

Formato:

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

Esempi di nomi di procedure: 

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

Incapsulo sempre le procedure memorizzate 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 concordare con tutti gli altri sviluppatori all'inizio del progetto.

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

per database più grandi, aggiungere uno schema o il nome del sottosistema, ad es. Ricezione, acquisto, ecc. Per tenerli raggruppati (dal momento che 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 significa 'UNAICFE' perché lo sproc è chiamato uspUsingNoAbbreviationsIncreasesClarityForEveryone)

Attualmente uso un formato simile al seguente

Notazione:

[prefisso] [APPLICAZIONE] [MODULO] _ [NAME]

Esempio:

P_CMS_USER_UserInfoGet

Mi piace questa notazione per alcuni motivi:

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

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 in base alla funzionalità, quindi è facile vedere cosa posso fare in una determinata tabella. Usando il prefisso & Quot; usp & Quot; fammi sapere come sto chiamando se (per esempio) sto scrivendo una procedura a 1000 righe che interagisce con altre procedure, più tabelle, funzioni, viste e server.

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

prefisso applicazione_ operazione prefisso_ descrizione degli oggetti del database coinvolti (meno gli spazi tra i caratteri di sottolineatura - è stato necessario inserire degli spazi affinché possano apparire) .

prefissi operativi che usiamo -

    &
  • # 8220; get # 8221 &; & # 8211; restituisce un recordset
    • &
  • # 8220; in # 8221 &; & # 8211; inserisce i dati
    • &
  • # 8220; UPD # 8221 &; & # 8211; aggiorna i dati
    • &
  • # 8220; del # 8221 &; & # 8211; elimina i dati

es

wmt_ ins _ customer _details

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

vantaggi

Tutte le procedure memorizzate relative alla stessa applicazione sono raggruppate per nome. All'interno del gruppo, le procedure memorizzate che eseguono lo stesso tipo di operazione (ad es. Inserti, aggiornamenti, ecc.) Sono raggruppate insieme.

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

Finora non ho riscontrato alcun svantaggio di questo approccio.

GetXXX: ottiene XXX in base a @ID

GetAllXXX - Ottiene tutti i XXX

PutXXX - Inserisce XXX se @ID passato è -1; altri 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 da quando 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'attuale applicazione 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 poter coesistere con un'applicazione legacy nello stesso database, quindi il prefisso è un must.

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

Dopo il prefisso di solito iniziamo il nome SP con un verbo che descrive cosa fa la procedura, quindi il nome dell'entità su cui operiamo. La pluralizzazione del nome dell'entità è consentita - Cerchiamo di enfatizzare la leggibilità, in modo che sia ovvio cosa fa la procedura dal solo nome.

I nomi tipici delle procedure memorizzate nel nostro team sarebbero: 

shopGetCategories
shopUpdateItem

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

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

dove la descrizione dell'azione fa parte di una piccola gamma di azioni tipiche come get, set, archive, insert, delete ecc. La descrizione del processo è breve ma descrittiva, ad esempio 

spu_archiveCollectionData

o 

spu_setAwardStatus

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

Ho visto persone tentare di usare la notazione pseudo-ungherese per la denominazione delle procedure, che secondo me nasconde più di quanto sveli. Finché quando elencherò le mie procedure in ordine alfabetico, le vedo raggruppate per funzionalità, quindi per me questo sembra essere il punto debole tra ordine e rigore inutile

Evita sp_ * nel server SQl perché tutte le procedure memorizzate nel 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, per cominciare, usiamo una denominazione comune di Proc_. Ciò semplifica l'identificazione delle procedure se presentato con un file di schema di grandi dimensioni.

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

Proc_Poll_Interface, Proc_Inv_Interface ecc.

Questo ci consente di trovare tutti i proc memorizzati che svolgono il lavoro di POLL rispetto a quelli di Inventario ecc.

In ogni caso il sistema di prefissi dipende dal dominio del problema. Ma al detto e fatto qualcosa di simile 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 ad es. di funzione. 

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Abbiamo seguito la denominazione basata sulle funzioni perché Procs è simile al codice / funzione piuttosto che agli oggetti statici come le tabelle. Non aiuta che Procs possa funzionare con più di una tabella.

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

Spero che sia d'aiuto.

Mi sono iscritto in ritardo alla discussione ma voglio inserire la mia risposta qui:

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

  

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

Queste convenzioni di denominazione sono seguite anche in front-end dal prefisso dt .

Esempio: 

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

Con l'aiuto delle convenzioni di denominazione sopra menzionate nella nostra applicazione abbiamo nomi validi e facili da ricordare.

Nel secondo progetto abbiamo usato le stesse convenzioni di denominazione con differenza di differenza:

  

Per ottenere i dati: sp _ < tablename > G
  Per eliminare i dati: sp _ & Lt; tablename & Gt; D
  Per inserire i dati: sp _ & Lt; tablename & Gt; I
  Per aggiornare i dati: sp _ & Lt; tablename & Gt; U

Esempio: 

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top