(解決済みにしますがなにか意見があればいただけるとうれしいです。)
社内で社員が利用する小規模なWEBアプリを構築することになりました。
データベース構築から入るということで先輩方が色々協議を重ねた結果テーブル構造が出来上がったのですが、その構造が簡単にあらわすと以下のようになっていました。
私はデータベース設計に詳しくないのですが、上記の図のようなデータベースの形というのはよくあるものなのでしょうか?
特に作業情報テーブルや項目マスタテーブル、作業場所グループマスタテーブルの形が教科書等で見たこと無いような形だったので気になりました。
プログラム的に扱いづらく、先輩方に構造を見直せないかお願いしたのですが、以下の理由でこの構造が良いといわれてしまいました。
- 作業情報の項目数(カラム数)を動的に変えられて便利(後から作業の種類が増える場合がある)
- 項目マスタの情報は本来もっと大量にあり、すべて作業情報テーブルに乗せようと思うとカラム数がとんでもないことになってしまう
私の知識不足で論破できなかったのですがあまり納得がいきません。私の言い分としては
- 項目数を変えるならALTER TABLEすればいい。
なぜか先輩方はALTER TABLEが嫌いらしく納得してくれませんでした。(項目数が頻繁に変わる場合がある?)
2. カラム数がとんでもないことにならないように作業の内容を分析してテーブルを分けるべき。
項目マスタテーブルに持っている作業結果形式は本来カラムのデータ型であるべきだと思うのでここもテーブル分ければ無くせる?
3. 作業情報テーブルから特定の作業日をSELECTするのが大変。作業情報テーブルの作業結果のうち複数の値を条件にSELECTしようとするとSQLが長くなってしまう
先輩曰く1つの作業にどの項目コードが存在するかを別の設定ファイルに記述しておき、ある社員がある作業日に実施したデータをSELECTする際は、条件文に設定ファイルから読み込んだ項目コードの一覧をOR条件で付けて検索しろとのことなのですが・・・
4. 作業場所グループに属する作業場所を変えようとしたら結局ALTER TABLEが必要になる。(項目数より頻繁に変わらないからいいのか?)
できれば構造を見直していただきたいのですが、知識と経験に自信が無く構造がこれこれこうだからだめと言い返しきれません。
このデータベースの問題点を指摘していただきたいです。
私が間違えている場合はその点も指摘していただけるとうれしいです。
また調べていると、作業情報テーブルの構造はSQLアンチパターンの「EAV」と呼ばれる構造に見えるのですがあってるでしょうか。
拙い日本語で申し訳ありませんがよろしくお願いします。
回答6件
あなたの回答
tips
プレビュー