I think MS had that at one point but they dropped it.

In general, carefully determine rules among yourselves and

most of all, consistently follow them.

FWIW, here are my suggested rules:

Avoid special characters, obviously, and do not start any name with a digit; underscores are OK, of course. In fact, I prefer them to "MixedCase" naming == mixed_case .

DO NOT prefix table names with "tbl" or the equivalent. It's unnecessary, and could be false, since if the table changes to a view you won't rename it anyway.

Table names are plural. Technically, I think singular names are more theoretically accurate, but the overwhelming number of table names are plural, so I swim with the river.

Same rules for views as tables, for the same reasons.

DO NOT use a table prefix on column names. For example, on the orders table: NOT ord_id, ord_date, ord_cust INSTEAD JUST id, order_date, customer, etc..

DO NOT put the (abbreviated) data type in a column name, except as part of a normal column name.

So, no intId or dttmOrderDate.

But order_date as column name is OK, of course, since "date" is inherently descriptive of the column data itself.

Decide on rules for naming table-related items -- indexes, constraints, triggers, etc. -- and stick to them. I prefer the "full_table_name__{CL|DF|IX|TR...}" as a prefix to all table "parts" (I think MS's practice of a "PK_" prefix makes NO sense).

But use any rules for that that meets your needs, JUST ENFORCE IT.

Policy-based mgmt is good for that, but you can even use after-the-fact queries to validate object names.