Generatore di nomi di tabelle di database

Cosa deve comunicare il nome di una tabella di database

Il nome di una tabella è un piccolo elemento architettonico. È presente in query, migrazioni, dashboard, log, avvisi, documentazione e conversazioni tra persone che potrebbero non condividere lo stesso contesto. Dovrebbe rivelare i record al suo interno e se la tabella è una sorgente, una relazione, una cronologia, una cache, un'area di staging o un controllo operativo. Nomi come CustomerContactDetails, UserRoleAssignments e SchemaMigrationLocks implicano aspettative diverse prima che una colonna venga ispezionata. Questo segnale riduce le congetture e supporta modifiche più sicure.

Scegliere nomi che sopravvivano a progetti reali

Iniziare con la responsabilità della tabella

Iniziare con una frase: questa tabella esiste per memorizzare cosa? La risposta dovrebbe identificare l'entità o l'evento centrale e, se necessario, lo scopo qualificante. Customer potrebbe essere troppo generico se i record contengono solo canali di contatto, stati di consenso o identità di fatturazione. CustomerContactDetails restringe la responsabilità senza elencare ogni colonna. Allo stesso modo, PaymentEvents suggerisce un flusso di sola aggiunta, mentre PaymentStatuses sembra una ricerca controllata. Il generatore copre nomi consapevoli delle colonne, flussi di eventi, modelli di preferenza, aggregazioni analitiche e altri modelli di schema ricorrenti in modo da poter confrontare i livelli di precisione.

Esporre le relazioni senza narrare lo schema

Le relazioni meritano un linguaggio visibile quando la tabella esiste principalmente per connettere i record. UserRoleAssignments è più chiaro di UserRoles quando ogni riga rappresenta un incarico con le proprie date, attore o ambito. InvoicePaymentAllocations segnala che un pagamento può essere suddiviso tra fatture, mentre ArticleTagLinks indica un'associazione più semplice. Evitare tuttavia di trasformare ogni chiave esterna in una frase. Una tabella di entità diretta dovrebbe comunque essere letta come un'entità. Aggiungere riferimenti, assegnazioni, appartenenze, associazioni o mappature solo quando la relazione stessa è il concetto duraturo.

Lasciare che le operazioni lascino indizi utili

I sistemi di produzione accumulano cronologia. MigrationExecutionLogs, CacheInvalidationEvents, FailedPaymentAttempts, DataErasureRequests e ResourceLocks rivelano il comportamento operativo nascosto dai nomi generici. Questi indizi aiutano gli ingegneri a capire se le righe sono mutabili, di sola aggiunta, temporanee, protette da regole di conservazione o utilizzate per coordinare il lavoro simultaneo. Il nome di una tabella non può sostituire i vincoli o la documentazione, ma può mettere in guardia contro aggiornamenti casuali. Quando un nome contiene Archived, Staged, Audit, Rollup, Lock o Request, verificare che lo schema e il ciclo di vita supportino effettivamente tale promessa.

La denominazione come parte dell'identità dello schema

Uno schema sviluppa un vocabolario proprio come un prodotto. I termini coerenti rendono più facile prevedere le join e aiutano gli analisti a individuare i dati autorevoli. Decidere se il progetto utilizza nomi singolari o plurali, se le tabelle di join utilizzano l'ordine alfabetico o l'ordine aziendale e se la cronologia è descritta come Eventi, Log, Audit o Revisioni. Distinguere il linguaggio di dominio stabile dai dettagli di implementazione. Una tabella denominata SubscriptionGracePeriods comunica un concetto di policy; una tabella denominata SubscriptionTemp2 comunica solo un momento dello sviluppo.

Controlli pratici di denominazione

• Denominare il concetto memorizzato, non la schermata o il servizio che attualmente lo scrive.
• Utilizzare sostantivi di relazione come Assegnazioni o Iscrizioni solo quando la relazione ha un significato proprio.
• Distinguere le tabelle sorgente da cache, rollup, importazioni, archivi e cronologie degli eventi.
• Verificare le convenzioni di singolare e plurale in tutto lo schema prima di introdurre un'eccezione.
• Evitare le abbreviazioni a meno che non siano già inequivocabili in tutto il prodotto e nel team.
• Leggere il nome all'interno di una SELECT, JOIN, migrazione e avviso per verificare che rimanga chiaro.

Domande che affinano un nome di tabella

Trattare ogni risultato generato come una domanda di progettazione piuttosto che come una risposta automatica. Chiedi a cosa serve la tabella, chi la scrive, per quanto tempo rimangono i record, se è possibile eliminare le righe e quale tipo di query verrà utilizzata più frequentemente. Confronta il nome proposto con quelli delle tabelle vicine e con le parole utilizzate nel codice. Una scelta finale efficace dovrebbe essere sufficientemente specifica da evitare confusione, abbastanza breve da poter essere utilizzata ripetutamente e abbastanza stabile da resistere alle future richieste di nuove funzionalità. Utilizza il generatore per confrontare le opzioni difendibili ed evidenziarne i compromessi.

• Un nuovo ingegnere saprebbe se le righe rappresentano lo stato attuale o eventi storici?
• Il nome rivela una relazione molti-a-molti senza esagerare?
• Questa tabella potrebbe essere confusa con una cache, una tabella di staging o un catalogo di ricerca?
• Quale termine del ciclo di vita avvertirebbe i lettori in merito a cancellazione, conservazione o immutabilità?
• Il nome sarà ancora appropriato se viene aggiunta un'altra colonna o un altro passaggio del flusso di lavoro?
• Il sostantivo scelto corrisponde al linguaggio utilizzato dai team di prodotto, supporto e analisi?

Quali sono dei buoni Nomi delle tabelle del database?

Questo generatore contiene migliaia di Nomi delle tabelle del database casuali. Ecco alcuni esempi da cui iniziare:

• CustomerContactDetails
• InvoicePaymentAllocations
• SchemaMigrationLocks
• ConsentWithdrawalEvents
• DailySalesRollups
• WorkflowStepOverrides
• ImportReconciliationReports
• DeadlockInvestigationLogs
• CacheStalenessChecks
• TaxRoundingDifferences