はじめに
昨年 ため息が出るDB設計書 の記事を作りましたが、その続編です。
概念設計がない、足りない
一般的な話と企業で最適化したアウトプットというものはあるとは思いますが、 「概念設計として少なくともER図くらいは書かなければいけないものではないでしょうか。
ER図はテーブル間の関連をつかむのに非常に適切であり、システムの全体像をつかむのにも役立ちます。
また、多対多の関係になっているなどのアンチパターンも検出・解消できるため概念設計の段階では 非常に有用なアウトプットであると考えます。
列名を頑張って英訳しすぎる
論理名を定めるとすべて英訳したくなるものではありますが、全てを英訳して長くなりすぎるパターンです。 例えば、
購入履歴詳細→detailed_purchase_history
ですが、テーブルの構成にもよりますが、 detailed hisutoryでも十分伝わる場合が多いと思います。
正確に書きたくなる気持ちはわかりますが、最短で伝わる言葉を選択することが重要かなと思います。
権限設定が適切ではない
アプリケーションから不要に強い権限のロール、ユーザーを使って操作しているなど。
あまりに強い権限は、DBのドロップができてしまったり、負荷のかかるコマンドを発行できたり、バグの温床以外にもセキュリティ的な観点で非常に危ういものとなります。
サニタライズに全てセキュアな面を持たせるよりもDB層でも適切な設定を行うことで強固なものになります。
同じようなテーブルが沢山ある
手続き毎にテーブルを作ってしまっている場合です。
確かに手続き毎に静的に残す必要があれば納得なのですが、手続き毎の画面をそのままテーブル化してしまうとこのようなパターンになります。
データ中心アプローチを行うことでこのようなことは回避されます。
終わりに
もっとDBのこと勉強しようよ! ということに尽きるでしょう。
わたしもまだまだ未熟ものですが、今の自分をイケてなかったなと思えるように精進したいものです。