今回は論理設計のアンチパターンの続きです。今までに比べると何も意図がないというものではなく、パフォーマンスを考えて設計されているようなものが多いです。中には絶対に許されないタイプのものもあるため、注意が必要なようです。3,000これは例えば上記のようなテーブルがあったとして、パフォーマンス向上を目的として、レコード数を絞りたいがために年度ごとにテーブルを分割してしまうようなケースです。意図はありますが、現実として下記のような欠点があります。分割する意味的な理由がないテーブルを分割する場合、正規化すべき理由がなければ基本的にテーブルを分割すべきではありません。拡張性に乏しいこのテーブルの場合、前年度のデータを総なめで検索することがないという前提が常に成り立っています。その前提が常になりたつかどうかは保証できませんし、カラムを追加する場合、複数のテーブルへの追加する必要がでてきます。他の代替手段があるこうした水平分割に代わる代替手段としてパーティションという機能があります。パーティション機能を用いることで、テーブルを分割することなく、特定のキーを軸として物理的に書く領域を分離することが可能になり、SQLがアクセスするレコード数を1/nに減らすことができます。インデックスとパーティションのどちらを使うかで迷うことがあるようですが、パーティションは一般的にはカーディナリティが小さく、値の変更があまり起きない列をキーにするときに利用します。典型的な例としては「年」や「都道府県」などカーディナリティが十~数十のものが対象になります。垂直分割これは水平分割よりもさらによくありそう。会社コード、社員ID、名前、部署コードのテーブル分けることを垂直分割といいます。これも正規化といった点から分割すべきでないテーブルですね。なんとなく意味的に分けておきたいからといった理由でたまに見かけることがあります。これらも下記のような代替手段があることからそれらを使うべきです。列の絞り込み本来のテーブルから特定の参照したい列だけを絞ったテーブルを新しいテーブルを作成し、定期的に同期するようにします。このようにして作られるテーブルのことをデータマート、あるいは単にマートと呼びます。サマリーテーブルサマリーテーブルも集約の一手段です。列の絞り込みと違い、集計関数を使い、レコードを集約した状態で保持することです。社員の平均年齢を見るときに会社コードごとの平均年齢を作成したテーブルをあらかじめ作っておくなどがこのようなテーブルになります。ともにもしテーブルを分割したい場合には上記のような技術を使うことが望ましいです。ともに同期しておかないと整合性がとれなくなることやこれらを作ることでストレージの容量を消費することにもつながります。これらがデメリットです。不適切なキーキーに関してはなるべく固定長文字列を使うべき、というのが本来のあり方のようです。いうのもキーはその性質上不変であることが望ましいため、長さが変わる可能性があるものはふさわしくないということですね。同じ文字列でも固定長文字列と可変長文字列では違った値として判定されます。私が今までやってきた現場ではそこまでの意識がなかったのか。可変長文字列でしたね・・・・ダブルマスタこれは全く同じ性質のテーブルが2つ(あるいはそれ以上)作られてしまうことです。0からシステムを構築した場合このようなことはめったに起きないのですが、もともと別のシステムで利用されていたマスタ同士が、システム統廃合によって同じドメインに存在する、となったときにこのようなことが起こってしまうようです。この場合、やはりデータをしっかり精査して、1つのテーブルに収めるのが正しい手法です。コメントをキャンセルメールアドレスが公開されることはありません。現在の開発ではデータベースへの接続ではJPAを使っています。このJPAがなかなか曲者でいろいろと詰まることがありましたので解説させていただきます。BYしたときに件数が増えるという現象があったので一応メモ。以下のようなテーブルがあったとします。以前SSHの設定についていろいろ書いたんで今回はMySQLに関して。複雑なJPQLを書いていると、通常のレコードの取り出しだけではなく、合計(SUM)や算出(COUNT)などのいわゆる算術関数を使うことが一般的です。JPQLでもこれらを通常通り扱うことができます。NULL時の動きHAVING句のNULLがあった時の挙動にたいしてメモリます。