Your views about the gap between naming convention of field names in Java bean and database

Question

In many past projects, I observed that people tend to keep database column name as two or three words separated with '_', for example : first_name. However the same column is mapped to Java bean's variable : firstName.

I don't know why people don't keep database field names like firstName but tend to use _ in between. Even if we use iBatis, it is an additional work to define resultmap mapping.

Regards, Jatan

Answer 1

Many databases have case insensitive column and table names (and this used to be even more the case than it is these days), so if you typed camelCasedColumnName, what you actually ended up with was CAMELCASEDCOLUMNNAME. Using underscores in your identifiers was much more readable in those databases, and a good practice even in case sensitive ones if you want to be able to change your backend database with a minimum of headaches.

On the code side, camelCase is the convention in Java for field identifiers, but in many other languages underscores are the convention for variable and method names. And there are tools that can convert between CamelCasedNames, underscored_names, or other formats without any additional effort on the developer's part when dealing with databases. (Ruby's ActiveRecord, for example, knows that a NameLikeThis for a class maps to a name_like_this for a table in your database.)

Answer 2

I usually use firstName even for database fields and it works fine! However, there might be some good reasons to use first_name. Probably, the dbms, team or company may have first_name notation for its databases or someone may love that notation!

Answer 3

Bear in mind that it is common for the database to be shared between several different applications. Those applications might be written in languages other than Java (if you can imagine such a thing). Even if the database is being built for a new application there may well be other applications interacting with it in the future.

Consequently it makes sense for the database to be named according to the norms for database schemas (which generally means case insensitivity and underscores) rather than trying to conform to the conventions of the front end's language.