Generator for databasetabellnavn

Hva et databasetabellnavn må kommunisere

Et tabellnavn er en liten del av arkitekturen. Det finnes i spørringer, migreringer, dashbord, logger, varsler, dokumentasjon og samtaler mellom personer som kanskje ikke deler samme kontekst. Det bør avsløre postene i tabellen og om den er en kilde, relasjon, historikk, hurtigbuffer, oppsamlingsområde eller driftskontroll. Navn som CustomerContactDetails, UserRoleAssignments og SchemaMigrationLocks har forskjellige forventninger før en kolonne inspiseres. Dette signalet reduserer gjetting og støtter tryggere endringer.

Velge navn som overlever virkelige prosjekter

Start med tabellens ansvar

Start med én setning: hva finnes denne tabellen for å lagre? Svaret bør identifisere den sentrale enheten eller hendelsen og, om nødvendig, det kvalifiserende formålet. Kunde kan være for bredt hvis postene bare inneholder kontaktkanaler, samtykkestatuser eller faktureringsidentiteter. CustomerContactDetails begrenser ansvaret uten å liste opp hver kolonne. På samme måte foreslår PaymentEvents en strøm som kun tilføyes, mens PaymentStatuses høres ut som et kontrollert oppslag. Generatoren spenner over kolonnebevisste navn, hendelsesstrømmer, preferansemodeller, analyseoppsummeringer og andre tilbakevendende skjemamønstre, slik at du kan sammenligne presisjonsnivåer.

Avslør relasjoner uten å fortelle skjemaet

Relasjoner fortjener synlig språk når tabellen primært eksisterer for å koble sammen poster. UserRoleAssignments er tydeligere enn UserRoles når hver rad representerer en tildeling med sine egne datoer, aktør eller omfang. InvoicePaymentAllocations signaliserer at en betaling kan deles på tvers av fakturaer, mens ArticleTagLinks indikerer en enklere tilknytning. Unngå imidlertid å gjøre hver fremmednøkkel om til en setning. En direkte enhetstabell bør fortsatt leses som en enhet. Legg til referanser, tildelinger, medlemskap, bindinger eller tilordninger bare når selve relasjonen er det varige konseptet.

La operasjoner legge igjen nyttige ledetråder

Produksjonssystemer akkumulerer historikk. MigrationExecutionLogs, CacheInvalidationEvents, FailedPaymentAttempts, DataErasureRequests og ResourceLocks avslører driftsatferd som generiske navn skjuler. Disse ledetrådene hjelper ingeniører med å forstå om rader er endrede, kun kan legges til, er midlertidige, beskyttet av oppbevaringsregler eller brukes til å koordinere samtidig arbeid. Et tabellnavn kan ikke erstatte begrensninger eller dokumentasjon, men det kan advare mot tilfeldige oppdateringer. Når et navn inneholder Arkivert, Staged, Revisjon, Samleoppdatering, Lås eller Forespørsel, må du bekrefte at skjemaet og livssyklusen virkelig støtter dette løftet.

Navngivning som en del av skjemaidentitet

Et skjema utvikler et vokabular akkurat som et produkt gjør. Konsistente termer gjør det enklere å forutsi sammenføyninger og hjelper analytikere med å finne autoritative data. Bestem om prosjektet bruker entalls- eller flertallsnavn, om sammenføyningstabeller bruker alfabetisk rekkefølge eller forretningsrekkefølge, og om historikk beskrives som hendelser, logger, revisjoner eller revisjoner. Skill stabilt domenespråk fra implementeringsdetaljer. En tabell med navnet SubscriptionGracePeriods kommuniserer et policykonsept; En tabell med navnet SubscriptionTemp2 kommuniserer bare et øyeblikk i utviklingen.

Praktiske navnesjekker

• Navngi det lagrede konseptet, ikke skjermbildet eller tjenesten som skriver det for øyeblikket.
• Bruk relasjonsnavn som Tildelinger eller Medlemskap bare når relasjonen har sin egen betydning.
• Skill kildetabeller fra hurtigbuffere, oppsummeringer, importer, arkiver og hendelseshistorikk.
• Sjekk entalls- og flertallskonvensjoner på tvers av hele skjemaet før du introduserer et unntak.
• Unngå forkortelser med mindre de allerede er entydige i hele produktet og teamet.
• Les navnet i en SELECT-, JOIN-, migrerings- og varsel for å teste om det forblir tydelig.

Spørsmål som skjerper et tabellnavn

Behandle hvert genererte resultat som et designspørsmål i stedet for et automatisk svar. Spør hva tabellen eier, hvem som skriver den, hvor lenge poster lever, om rader kan slettes og hva slags spørring som vil søke i dem oftest. Sammenlign det foreslåtte navnet med tabeller i nærheten og med ordene som brukes i koden. Et sterkt endelig valg bør være spesifikt nok til å forhindre forvirring, kort nok til å brukes gjentatte ganger og stabilt nok til å overleve neste funksjonsforespørsel. Bruk generatoren til å sammenligne forsvarbare alternativer og avsløre avveiningene deres.

• Ville en ny ingeniør vite om rader er gjeldende tilstand eller historiske hendelser?
• Avslører navnet et mange-til-mange-forhold uten å overdrive det?
• Kan denne tabellen forveksles med en hurtigbuffer, en oppsamlingstabell eller en oppslagskatalog?
• Hvilket livssyklusord ville advare leserne om sletting, oppbevaring eller uforanderlighet?
• Vil navnet fortsatt passe hvis én kolonne eller ett arbeidsflyttrinn til legges til?
• Samsvarer det valgte substantivet språket som brukes av produkt-, support- og analyseteamene?

Hva er gode Navn på databasetabeller?

Det finnes tusenvis av tilfeldige Navn på databasetabeller i generatoren. Her er noen eksempler å begynne med:

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