Database Table

Read the table before the columns

A database table name is repeated everywhere the data travels: application code, SQL, migrations, dashboards, incident reports, and team discussions. That repetition makes naming an architectural choice. Entity names such as CustomerContactDetails should identify the records directly. Relationship names such as UserRoleAssignments should make the association itself visible. Operational names such as SchemaMigrationLocks should tell readers that the table coordinates work rather than representing a business object.

Match the name to the data lifecycle

The lifecycle often supplies the most important qualifier. PaymentEvents implies append-only history. DailySalesRollups implies derived aggregates. StagedCustomers suggests temporary imported records awaiting validation. ArchivedCustomerRecords warns that the rows are not active. CacheInvalidationEvents points to coordination around derived data. DataErasureRequests carries privacy and workflow expectations. Choose these words only when the table’s constraints, retention, and write patterns make them true.

Use domain language with technical precision

Good names align product vocabulary with database structure. Use terms recognized by support, finance, operations, and analytics, then add technical qualifiers only when they prevent a real ambiguity. InvoicePaymentAllocations is useful when allocation is a first-class action. CountryCodes is enough for a restrained lookup. TenantNotificationRules is appropriate when every row belongs to a tenant. Avoid implementation souvenirs such as temporary version numbers or service names that may disappear while the data remains.

A quick naming review

• State the central entity or event first.
• Reserve Logs, Events, Audits, and History for genuinely different lifecycles.
• Make join-table language consistent across the schema.
• Use Staged, Cached, Archived, or Rollup only when the qualifier is operationally true.
• Prefer stable domain nouns over temporary implementation labels.

Questions for the next migration

Before accepting a generated name, test it in a join, a migration title, and an alert. Ask whether it identifies the owner of the data, whether it distinguishes current state from history, and whether another table already claims the same noun. Then choose the shortest name that keeps those distinctions intact.

• What would an on-call engineer infer from the name alone?
• Which word distinguishes this table from its nearest neighbor?
• Does the name still work after the current feature is replaced?
• What constraint or lifecycle should the name quietly signal?