DB column names are generally named in such a way that it is easy to visualize what kind of data is contained in them.
Because DB objects have many patterns in column names, naming conventions are often not defined down to words, which can easily induce broken windows theory.
Despite the fact that there is a general flow in naming DB columns, there are people who ignore it and use the names of program functions or naming conventions as they are for DB columns, and I have had trouble convincing them of this.
Columns and Fields
Column names correlate with field names and are nearly identical, but are not strictly perfect equals.
Even if they are to be the same as the field name, in most cases you should use a noun, noun phrase, or adjective to name the field.
Microsoft Names of Type Members
programmatic thinking
People who are comfortable with program-based naming are "program-oriented in their thinking because they start with programs and only touch DB," and they view the DB area as the same as programs.
Although there are some frameworks that encourage this, and I think it cannot be helped, there is a correlation, but it is not the same at all.
Even if you can only think programmatically, you should at least read the code-complete.
From a DBA perspective, articles by people urging you to gut the DB area are gone and gone today.
Therefore, the reference or justification sources are "program naming conventions blogs" or "articles written by individuals or companies to appeal to the public" which were common at one time.
The trouble with today's society is that there are tons of unrelated blogs and junk articles that are not written in the reference source, not the main point of the article, so this phenomenon seemed to occur because only the convenient parts were cut out.
Separation is critical.
how to think originally
The first thing is to avoid meshing with reserved words: since SQL and commands are instructions to change states, they contain verbs rather than reserved words.
The less you use verbs as much as possible, the less you will be subjected to them.
If you wrote use_xxx or something like that in the mysql environment at your last job, you will definitely get a power harassment.
I don't deny that if you can take responsibility for the unintended SQL run due to a writing error in your work, a bug in a library or framework, or a vulnerability-tired attack, including apologies to the customer and data integrity, as well as consistency of meaning, but there are fewer cases where it is clear to use it.
As EdStevens (DBA) posted, to begin with, most data element names are either nouns or adjectives + nouns.
reference : Is there a non-syntactical guide for naming database columns? [closed]
Another common column named "user_role" originally meant "user_has_role".
Either one is fine, but in general, you should use the one with the verb omitted.
Otherwise, we would be in a world where everything around the DB is explained in sentences, but that is not the case in this world line.
In many conventions, verbs and auxiliary verbs are rarely used, and in most cases are nouns, so the use of verbs and auxiliary verbs is unthinkable.
microsoft/sql-server-samples | AdventureWorks sample databases
If you cannot determine if something is wrong, modeling with entity-relational data modeling will tell you.
Exceptional cases
There are two possible examples of the few cases where the use of a verb in the name makes it easier to understand.
One is when a third column is needed that describes the relationship between two columns. With tables, examples would be the intersection table and the comprehension table.
The second is a word that seems to have citizenship. Words that have citizenship tend to be treated like proper nouns.
Because games usually have information related to character movement or unrealistic phenomena, such as game systems, it is sometimes easier to understand them if they have names that are civil rights. fly (verb) and flight (noun), for example.
A fad is something to think about
I've seen some urging the use of is_, but if you want to do it this way, it's for databases where boolean types exist for data that is managed by boolean values.
In the example of DB construction, "is_active" is created with the boolean type, and the boolean used in the program is used in a place where it is registered in the DB as it is.
If this is used as 0/1 in the program, when creating a boolean method based on the column contents, it will result in strange names such as "isIsActive" or "isXxxxIsActive".
The latest naming fad, which is often the case, is essentially a problem that comes from people who don't understand the classical meaning of the name, who got involved, and the data is inconsistent with the name, or the name is perverse, and it is like a counter to that.
It is an illusion of cargo cult best practices to use something trendy because it has a particular name or because the framework is easy.
Some people try to give it a different name than the whole in order to make it look good, but it is far more important to remain consistent in approach.
Final Thoughts
No convention is necessarily right or wrong, and there is no such thing as a one-size-fits-all solution.
And while naming cannot be enforced, even worse than a wrong naming convention is the mixing of multiple naming conventions.
If you already have an approach for naming database objects in an existing project, keep using it.
Even if there is no naming convention, be careful of broken windows and do not be dominated by the broken one.
