Generator voor databasetabelnamen

Wat een tabelnaam in een database moet communiceren

Een tabelnaam is een klein stukje architectuur. Hij komt voor in query's, migraties, dashboards, logboeken, waarschuwingen, documentatie en gesprekken tussen mensen die mogelijk niet dezelfde context delen. De naam moet de records in de tabel onthullen en aangeven of de tabel een bron, relatie, historie, cache, staging area of ​​operationele controle is. Namen zoals CustomerContactDetails, UserRoleAssignments en SchemaMigrationLocks roepen verschillende verwachtingen op voordat een kolom wordt gecontroleerd. Dat signaal vermindert giswerk en ondersteunt veiligere wijzigingen.

Namen kiezen die bestand zijn tegen echte projecten

Begin met de functie van de tabel

Begin met één zin: waarvoor dient deze tabel? Het antwoord moet de centrale entiteit of gebeurtenis identificeren en, indien nodig, het kwalificerende doel. 'Klant' kan te breed zijn als de records alleen contactkanalen, toestemmingsstatussen of factureringsidentiteiten bevatten. 'CustomerContactDetails' beperkt de functie zonder elke kolom op te sommen. Evenzo suggereert PaymentEvents een stream die alleen gegevens kan toevoegen, terwijl PaymentStatuses klinkt als een gecontroleerde lookup. De generator omvat kolombewuste namen, gebeurtenisstreams, voorkeursmodellen, analyse-rollups en andere terugkerende schema-patronen, zodat u de precisieniveaus kunt vergelijken.

Laat relaties zien zonder het schema te beschrijven

Relaties verdienen zichtbare taal wanneer de tabel primair bestaat om records te verbinden. UserRoleAssignments is duidelijker dan UserRoles wanneer elke rij een toewijzing vertegenwoordigt met zijn eigen datums, actor of bereik. InvoicePaymentAllocations geeft aan dat een betaling over meerdere facturen kan worden verdeeld, terwijl ArticleTagLinks een eenvoudigere associatie aangeeft. Vermijd echter om van elke foreign key een zin te maken. Een tabel met directe entiteiten moet nog steeds leesbaar zijn als een entiteit. Voeg alleen referenties, toewijzingen, lidmaatschappen, bindingen of mappings toe wanneer de relatie zelf het duurzame concept is.

Laat bewerkingen nuttige aanwijzingen achterlaten

Productiesystemen verzamelen geschiedenis. MigrationExecutionLogs, CacheInvalidationEvents, FailedPaymentAttempts, DataErasureRequests en ResourceLocks onthullen operationeel gedrag dat generieke namen verbergen. Deze aanwijzingen helpen engineers te begrijpen of rijen wijzigbaar, alleen-toevoegend, tijdelijk, beschermd door bewaarregels of gebruikt worden om gelijktijdig werk te coördineren. Een tabelnaam kan beperkingen of documentatie niet vervangen, maar kan wel waarschuwen voor onbedoelde updates. Wanneer een naam Archived, Staged, Audit, Rollup, Lock of Request bevat, controleer dan of het schema en de levenscyclus die belofte daadwerkelijk ondersteunen.

Naamgeving als onderdeel van schema-identiteit

Een schema ontwikkelt een vocabulaire, net als een product. Consistente termen maken joins gemakkelijker te voorspellen en helpen analisten bij het vinden van gezaghebbende gegevens. Bepaal of het project enkelvoudige of meervoudige zelfstandige naamwoorden gebruikt, of join-tabellen alfabetisch of zakelijk gesorteerd zijn en of de geschiedenis wordt beschreven als Events, Logs, Audits of Revisions. Onderscheid stabiele domeintaal van implementatiedetails. Een tabel met de naam SubscriptionGracePeriods communiceert een beleidsconcept; een tabel met de naam SubscriptionTemp2 communiceert slechts een moment in de ontwikkeling.

Praktische naamgevingscontroles

• Geef het opgeslagen concept een naam, niet het scherm of de service die het momenteel schrijft.
• Gebruik relatie-zelfstandige naamwoorden zoals Assignments of Memberships alleen wanneer de relatie een eigen betekenis heeft.
• Onderscheid brontabellen van caches, rollups, imports, archieven en gebeurtenisgeschiedenissen.
• Controleer de conventies voor enkelvoud en meervoud in het hele schema voordat u een uitzondering introduceert.
• Vermijd afkortingen, tenzij ze al ondubbelzinnig zijn in het hele product en team.
• Lees de naam in een SELECT, JOIN, migratie en alert om te testen of deze duidelijk blijft.

Vragen die een tabelnaam aanscherpen

Beschouw elk gegenereerd resultaat als een ontwerpvraag in plaats van een automatisch antwoord. Stel vragen over de gegevens die in de tabel worden opgeslagen, wie de gegevens schrijft, hoe lang records bewaard blijven, of rijen verwijderd kunnen worden en welk type query er het vaakst op wordt uitgevoerd. Vergelijk de voorgestelde naam met vergelijkbare tabellen en met de woorden die in de code worden gebruikt. Een goede definitieve naam moet specifiek genoeg zijn om verwarring te voorkomen, kort genoeg om herhaaldelijk te gebruiken en stabiel genoeg om een ​​volgend functieverzoek te overleven. Gebruik de generator om verdedigbare opties te vergelijken en de afwegingen ervan bloot te leggen.

• Zou een nieuwe engineer weten of rijen de huidige status of historische gebeurtenissen weergeven?
• Onthult de naam een ​​vele-op-vele-relatie zonder deze te overdrijven?
• Zou deze tabel verward kunnen worden met een cache, stagingtabel of opzoekcatalogus?
• Welk woord uit de levenscyclus zou lezers waarschuwen voor verwijdering, bewaring of onveranderlijkheid?
• Past de naam nog steeds als er een extra kolom of workflowstap wordt toegevoegd?
• Komt het gekozen zelfstandig naamwoord overeen met de taal die wordt gebruikt door product-, support- en analytics-teams?

Wat zijn goede Namen van databasetabellen?

Deze generator bevat duizenden willekeurige Namen van databasetabellen. Hier zijn enkele voorbeelden om mee te beginnen:

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