Come si tiene traccia del significato dei propri campi SQL? [chiuso]

Che ne dici di un sistema di denominazione logico semanticamente corretto che eviti la duplicazione, la tautologia e le abbreviazioni?

Questo e un glossario e un diagramma ER logico / fisico del database, preferibilmente ospitato su un Wiki di qualche tipo, è tutto ciò che puoi fare.

Inoltre ciò che Jason Holland dice nel commento sotto ! : -)

SQL Management Studio ha la possibilità di aggiungere una descrizione per le colonne, ma non l'ho mai trovato utile, mai. Ho anche provato a lavorare per usare documenti, wiki e what-have-you per documentare la struttura del DB. Dopo un tempo sufficiente, nessuno disturba però. Le date di rilascio non attendono nulla.

Uno schema di denominazione coerente e coerente non ti deluderà. Non aver paura di usare nomi di colonna più lunghi e descrittivi se ne senti la necessità, è meglio garantire il futuro: puoi dare un senso alla struttura.

Attualmente sto lavorando su un DB di colonne 1600+ che è un incubo di nomi incoerenti; atteniti al tuo stile!

Un suggerimento:

• chiama la colonna della chiave primaria per includerla, quindi non "ID", ma "ClientID". Rende più semplice la lettura delle query.
• decidere e attenersi ai nomi delle tabelle singolarmente o al plurale (ad esempio tblClient vs tblClients)
  • Il mio sé logico preferisce il singolare
• preferisci raggruppare tabelle simili insieme, ad esempio la ricerca del prefisso / tabelle statiche con tblLUT / lookup_
• lo stesso vale per il raggruppamento di clienti, lavori, attività, Cheezeburgers e simili
• usa stored procedure e viste personalizzate, un lotto di loro, per recuperare i tuoi dati
  • questo normalizza l'accesso ai dati, fornendo un livello superiore di accesso ai dati

Su una nota semi-correlata, ho trovato di recente uno strumento server SQL alternativo, con questa caratteristica elegante per generare classi di codice basate sulle strutture della tabella, prendendo un lettore di dati nel costruttore, rende il lavoro davvero pratico. ha mi ha fatto capire che le tabelle e i campi di denominazione senza tbl e f prefissi è un po 'carina per strumenti come questi. ( SQL Anywhere di Atlantis Interactive )

Suggerirei di raggruppare le tabelle in domini logici e visualizzarle su un poster. È possibile creare e preparare file stampabili con l'aiuto di ER studio / SSMS.

Soprattutto, la denominazione delle colonne deve essere strettamente correlata al dominio per evitare di nominare ulteriori ambiguità a lungo termine.

Poiché utilizzi MSSQL, se riesci a distribuire un sito Web, metti insieme un piccolo sito che interroga i cataloghi di sistema per le informazioni che desideri documentare. Collegati al tuo database e vai a Views - > Viste di sistema per vederli.

Ignorerei le viste in INFORMATION_SCHEMA perché, mentre forniscono un formato più user-friendly se si vuole solo guardarle direttamente, mancano alcune informazioni utili. Le viste nello schema "sys" contengono tutto.

Quelli che probabilmente vorrai iniziare a guardare sono:

sys.types
sys.objects
sys.tables
sys.columns
sys.indexes
sys.procedures
sys.views
sys.parameters
sys.schemas
sys.foreign_keys
sys.foreign_key_columns
sys.extended_properties

Se hai problemi a capire il significato delle colonne in queste viste, sono tutte documentate in Books Online / MSDN. La maggior parte di questi dovrebbe essere auto esplicativa, tranne forse sys.extended_properties. Ecco dove Management Studio salva le descrizioni. Se aggiungi una descrizione a una tabella e la salvi, fai clic con il pulsante destro del mouse sulla tabella in Esplora oggetti e seleziona Proprietà, quindi Proprietà estese vedrai la descrizione. Puoi aggiungere una quantità arbitraria di proprietà estese alle cose, e questo può essere davvero utile per la documentazione, a seconda di cosa vuoi documentare e di quanto dettagliato vuoi ottenere.

Se si desidera consentire la modifica delle descrizioni nel sito stesso, è possibile utilizzare la sys.sp_addextendedproperty , sys.sp_updateextendedproperty e sys.sp_dropextendedproperty stored procedure.

Infine, se si desidera documentare dove viene fatto riferimento a una tabella / vista / ecc. nel database, è possibile utilizzare sys.sp_depends stored procedure per ottenere tali informazioni.

La cosa bella di questo approccio è che la tua documentazione sarà esattamente aggiornata come il database stesso. Esaminare una definizione di tabella e aggiungere una nuova colonna alla tabella? Aggiorna la pagina ed è lì. Anche se, se vuoi avere una documentazione che è solo un'istantanea, puoi farlo anche tu. E ottieni qualcosa che puoi navigare e in un formato che evita il clunkiness di cercare di leggere i campi descrittivi in SSMS.

La migliore denominazione del mondo non può aiutarti a conoscere i dettagli del perché esista un campo o che cosa cercare nei dati. Controlla Database Note Taker che è uno strumento gratuito più leggero che ti consente di aggiungere una spiegazione agli oggetti del tuo database. Potrebbe essere una breve nota, potrebbe essere una descrizione più lunga con query di esempio e l'uso della sintassi markdown per la formattazione. Mantiene i tuoi commenti in un file di progetto separato che è compatibile con il controllo del codice sorgente.