テーブル定義でスネークケースをやめたい

#スネークケースとは
テーブル定義では、スネークケース(_区切り)で定義することが多い。
例えば、ユーザー情報を格納するマスタの例で説明する。
テーブル名：mst_user

論理名	物理名
ユーザーID	user_id
ユーザー名	user_name

#アプリケーション開発との関連
アプリケーション開発言語はスネークケースではないことが多い。
例えば、javaの場合、パスカルケースとキャメルケースだったりする。

#何が問題か
javaを例にあげると、mst_userに対応するクラス(DTO)はJavaの規約(パスカルケース、キャメルケース)に従うと以下のようになる。

public class MstUser {
    private String userId;
    private String userName;

    // getter,setterは省略
}

テーブルはスネークケースなのにjavaの規約が異なるためマッピングが必要となる。
これに付随する問題がいくつか発生する。

1. 仕様書作成時の負担が大きい
   例）API仕様書作成時に間違える。
   大抵は項目が多いのでテーブル定義から項目をコピーしてスネークケースをキャメルケースに置き換えていくことになるが間違えやすい。
   user_id => userid => 間違えた！
   特に、設計だけして開発を外部に依頼する場合、「userIdでは?」とQ&Aがきたりして時間の無駄。

2. 開発時にマッピングミスすると面倒
   SQLがスネークケースのため、javaのクラスへのマッピングを記載する必要がある。
   ORマッパーで自動生成できれば、結合(join)するような仕様だと地道にマッピングを書くことになるのでミスする可能性がある。値の取得結果がnullになる=>マッピングミスだったということが起こる。

3. スネークケースとキャメルケースの相互変換が面倒
   1,2とも関連するが、そもそもマッピングをする際にスネークケース=>キャメルケース、キャメルケース=>スネークケースの変換をするのがかなりの手間になる。
   ツールを作れば多少はマシになるかもしれないが、やっぱり手間である。

#スネークケースをやめて開発言語の規約に合わせる
javaの規約に従ってみる。

テーブル名：MstUser

論理名	物理名
ユーザーID	userId
ユーザー名	userName

DTO

public class MstUser {
    private String userId;
    private String userName;

    // getter,setterは省略
}

これでマッピングの手間がなくなるので、効率よく設計、開発ができそう。
デメリットはあるだろうか？

目次