システム設計Tweetずっと前から積ん読状態だった「SQLアンチパターン」を読みました。何年積んでたか分からないSQLアンチパターン読み終わったー。噂に違わずいい本ですねー。噂通りとても良い本で、まさに「エンジニアとしての血肉本」と言えます。2年目の頃に読んでおくべきだったなーと少し後悔しています。見る読んで終わりだと身につかないと思うので、自分なりのチェックポイントを言語化しておこうと思います。長くなってしまったので、章ごとに4つに分けたいと思います。この記事はその第一弾となります。ポイントが幾つか紹介されていますが、その中の一部(自分が重要だと思ったもの)のみを記載しています。良い設計方法についても同様で、代表的なもののみ書いている部分があります。自分用のチェックポイント、インデックスにしたくて作成したので、選択が良くないものがあれば申し訳ありません。データベース論理設計のアンチパターンチェックリストデータベース論理設計についてこの記事では整理します。論理設計をしくじったアプリケーションをメンテすると、生産性が非常に落ちることは多くのエンジニアの方が経験していると思います。それに気付いたときには、既にデータが大量に追加されており、最適化したくても手が出しにくい状況になっていることも頻繁にあるのではないでしょうか?そうならないために、最低限押さえておくべきポイントが8つ紹介されていました。詳細はこのあと記載しますが、チェックすべきポイントのサマリは下記の通りです。(ただし、各項目ごとに「許容してもいい場合」という紹介もあるので、詳しくは本を参照してみてください。複数個の要素を持つ場合のテーブル設計をすることを考える。交差テーブルを用いるようにする。ナイーブツリー(素朴な木):3世代以上の階層があるデータ構造を扱う場合に、直接の親子関係のみを参照する形にしていないか?アンチパターン例このような階層構造を表したい場合(例えば、連絡網など)に、下記のように直接の親子関係をのみを表現する形にしてしまうと、幾つか問題が発生する。090-xxxx-xxxx例えば「2を消したい」場合、繋ぎ直しのコストが非常に大きくなってしまう。「2以下を全部消したい」場合、まずは子供を辿った上で、子供から削除していくような処理が必要になる。今回のような小さい例であれば問題ないが、階層が大きくなると非常に辛い処理になる。必要になるが、ノードを削除する場合(そのノードが関連するレコードを全て削除すれば良い)も、サブツリーを削除する場合(シンプルに上から順に消していくでいい)もコストが低くメンテナンス性が高い。定義してしまうパターン。分かりやすい名前にする。複合主キーにできないか考える。表す列を作成してしまっていないか?あるテーブルで可変属性(レコードによってある/なしのある属性)を扱いたい場合の設計。テーブルを作成することを考える。管理するといったように、レコードのタイプによって、入力される列が異なる場合がある。いう列を追加してしまうパターン。)必須にできない何が入るかわからないので適切な型も設定できないなど、負債になる原因をいくつも生み出してしまう。継承の考え方を用いる。作成することを考える。(Teacher|Student)の主キーの値が入る「想定」という設計とする。テーブルを外部キー参照したいができない。するテーブルを決定する形にするので、クエリが複雑になりますといった負債につながってしまう。