Data Architecture

Database Naming Standards Validator

Checks names against the rules that have a reason behind them, with the reason stated for each finding.

Loading the tool…

Processing happens locally in your browser. What you paste or load is processed by this page and is not uploaded to a server. Nothing is stored unless you use a control that says it stores something, and you can clear anything this site has kept from the privacy page.

How to use this tool

  1. Paste your column or table names, one per line.
  2. Set the maximum length to whatever your platform enforces — 30 suits Oracle, 63 suits PostgreSQL, 128 suits SQL Server.
  3. Turn on abbreviation flagging only if you intend to spell names out; most teams keep a few abbreviations on purpose.
  4. Select Validate names and fix the high severity findings first — those break things rather than merely annoying people.

What naming standards validator does

This is the other half of naming, and it is the half with consequences. A column called "order" needs quoting in every query that touches it, and the one query that forgets fails with a syntax error nobody attributes to the name. A column called email_str becomes a lie the day the type changes. A column called created is indistinguishable from a description until you open the table.

Every finding here says what the rule is and why it exists, because a standards report that only cites a rule number gets ignored, and it deserves to be. Findings are ranked, and the ranking is honest about the difference: a reserved word will break something, while an unexpanded abbreviation will only ever cost a reader a moment. Use the naming convention checker for the separate question of casing.

Frequently asked questions

ORDER is a keyword in every mainstream SQL dialect. You can use it as a column name if you quote it, and quoting works right up until the one query, view or generated statement that forgets — which then fails with a syntax error that reads as a typo rather than as a naming problem. The list here covers words reserved in at least one major dialect, so it is deliberately broader than any single platform requires.

The type is already in the type, so email_str carries no information the schema does not have. The cost arrives when the column changes: the day it becomes a date, the name is a lie, and renaming it means touching everything downstream, so it usually stays wrong forever. The same applies to _int, _num, _dt and the rest.

It is the lowest severity finding here for a reason. The argument is that a boolean named for the question reads unambiguously in a WHERE clause, where a boolean named for the thing does not — WHERE is_active is obvious, WHERE active_flag leaves the reader wondering what value counts as true, particularly on the many flag columns that turn out to hold Y and N rather than a boolean. If your house style is active_flag consistently applied, keeping it is defensible.

Match your platform: Oracle allowed 30 bytes before 12.2 and 128 after, PostgreSQL truncates at 63, SQL Server allows 128, and most cloud warehouses are generous. The reason the check exists is that older platforms truncate rather than reject, which can silently turn two long names into one duplicate — and that failure is far more confusing than an error would have been.