Generator för databastabellnamn

Vad ett databastabellnamn behöver kommunicera

Ett tabellnamn är en liten del av arkitekturen. Det finns i frågor, migreringar, instrumentpaneler, loggar, aviseringar, dokumentation och konversationer mellan personer som kanske inte delar samma kontext. Det bör visa posterna inuti och om tabellen är en källa, relation, historik, cache, mellanlagringsområde eller operativ kontroll. Namn som CustomerContactDetails, UserRoleAssignments och SchemaMigrationLocks har olika förväntningar innan en kolumn inspekteras. Den signalen minskar gissningsarbetet och stöder säkrare ändringar.

Välja namn som överlever verkliga projekt

Börja med tabellens ansvar

Börja med en mening: vad finns den här tabellen för att lagra? Svaret bör identifiera den centrala enheten eller händelsen och, vid behov, det kvalificerande syftet. Kund kan vara för brett om posterna bara innehåller kontaktkanaler, samtyckestillstånd eller faktureringsidentiteter. CustomerContactDetails begränsar ansvaret utan att lista varje kolumn. På samma sätt föreslår PaymentEvents en ström som endast tilläggsfunktioner, medan PaymentStatuses låter som en kontrollerad sökning. Generatorn spänner över kolumnmedvetna namn, händelseströmmar, preferensmodeller, analysuppsättningar och andra återkommande schemamönster så att du kan jämföra precisionsnivåer.

Exponera relationer utan att berätta schemat

Relationer förtjänar synligt språk när tabellen främst finns för att koppla samman poster. UserRoleAssignments är tydligare än UserRoles när varje rad representerar en tilldelning med sina egna datum, aktör eller omfattning. InvoicePaymentAllocations signalerar att en betalning kan delas upp över fakturor, medan ArticleTagLinks indikerar en enklare association. Undvik dock att förvandla varje främmande nyckel till en mening. En direkt entitetstabell bör fortfarande läsas som en entitet. Lägg till referenser, tilldelningar, medlemskap, bindningar eller mappningar endast när själva relationen är det hållbara konceptet.

Låt operationer lämna användbara ledtrådar

Produktionssystem ackumulerar historik. MigrationExecutionLogs, CacheInvalidationEvents, FailedPaymentAttempts, DataErasureRequests och ResourceLocks avslöjar operativt beteende som generiska namn döljer. Dessa ledtrådar hjälper ingenjörer att förstå om rader är föränderliga, endast tilläggsbara, tillfälliga, skyddade av lagringsregler eller används för att koordinera samtidigt arbete. Ett tabellnamn kan inte ersätta begränsningar eller dokumentation, men det kan varna för tillfälliga uppdateringar. När ett namn innehåller Arkiverad, Staged, Granskning, Sammanslagning, Låsning eller Begäran, verifiera att schemat och livscykeln verkligen stöder det löftet.

Namngivning som en del av schemaidentitet

Ett schema utvecklar ett ordförråd precis som en produkt gör. Konsekventa termer gör det lättare att förutsäga kopplingar och hjälper analytiker att hitta auktoritativa data. Bestäm om projektet använder substantiv i singular eller plural, om kopplingstabeller använder alfabetisk ordning eller affärsordning och om historik beskrivs som händelser, loggar, granskningar eller revisioner. Skilj stabilt domänspråk från implementeringsdetaljer. En tabell med namnet SubscriptionGracePeriods kommunicerar ett policykoncept; En tabell med namnet SubscriptionTemp2 kommunicerar bara ett ögonblick i utvecklingen.

Praktiska namngivningskontroller

• Namnge det lagrade konceptet, inte skärmen eller tjänsten som för närvarande skriver det.
• Använd relationsnamn som Tilldelningar eller Medlemskap endast när relationen har en egen betydelse.
• Skillnad mellan källtabeller och cacher, sammanslagningar, importer, arkiv och händelsehistorik.
• Kontrollera singular- och pluralkonventioner över hela schemat innan du introducerar ett undantag.
• Undvik förkortningar om de inte redan är entydiga i hela produkten och teamet.
• Läs namnet inuti en SELECT-, JOIN-, migrerings- och varning för att testa om det förblir tydligt.

Frågor som skärper ett tabellnamn

Behandla varje genererat resultat som en designfråga snarare än ett automatiskt svar. Fråga vad tabellen äger, vem som skriver den, hur länge poster lever, om rader kan tas bort och vilken typ av fråga som söker i dem oftast. Jämför det föreslagna namnet med närliggande tabeller och med orden som används i koden. Ett starkt slutgiltigt val bör vara tillräckligt specifikt för att förhindra förvirring, tillräckligt kort för att användas upprepade gånger och tillräckligt stabilt för att överleva nästa funktionsförfrågan. Använd generatorn för att jämföra försvarbara alternativ och avslöja deras avvägningar.

• Skulle en ny ingenjör veta om raderna är aktuellt tillstånd eller historiska händelser?
• Avslöjar namnet en många-till-många-relation utan att överdriva den?
• Kan denna tabell förväxlas med en cache, en mellanlagringstabell eller en sökkatalog?
• Vilket livscykelord skulle varna läsare om borttagning, kvarhållning eller oföränderlighet?
• Kommer namnet fortfarande att passa om ytterligare en kolumn eller ett arbetsflödessteg läggs till?
• Matchar det valda substantivet språket som används av produkt-, support- och analysteamen?

Vilka är bra Namn på databastabeller?

Det finns tusentals slumpmässiga Namn på databastabeller i generatorn. Här är några exempel att börja med:

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