skillup

技術ブログ

Database プログラミング全般

オブジェクト指向 データベース層

投稿日:

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。

本日は主にデータベース層の考え方について。

データべース層

要点

典型的なダメテーブル設計

  • 既存DBの問題点(意味不明なカラム、NULLが入っている、ダブルミーニング、関係がわからない、テーブルが巨大すぎ)
  • 制約(ユニークキーがない、NOT NULLがない、外部キー制約がない)
  • 1つのカラムに複数の意味と思われるデータが入っている
  • テーブル間の関係がしっかりしていない

基本的には下記のリンクでかいたようなネタ

論理設計のアンチパターン その2
論理設計のアンチパターン
データベースアンチパターン・グレーパターンまとめ

対策

  • カラム時の制約を整理(not null,FK,ユニーク他)
  • 記録のタイミングが違う場合はテーブルを分ける
  • UPDATE文をなるべく使わず、INSERTで履歴を追加する
  • カラム追加時はテーブルの分割を考える(ただし非正規化が崩れる)
  • 複数の更新作業は非同期で行ってもよい(ただし複数のサーバー分割などデメリットもあり)
  • 集計はイベントの記録から動的に作成する(ビューや中間テーブルを使わない)
  • オブジェクトとテーブルは似てはいるが違うもの

感想

今回はデータベースがらみの話。結構いろいろな本を読んで勉強しまして、半分以上は知っている話だったんですが、UPDATEを使わないってのは初でしたね。確かに今作ってるアプリでも履歴をつくってデータを消さないってのはあるんですけど、INSERTとDELETEだけってのは聞いたことがありませんでした。私がまだ考えを理解できていないだけかもしれませんが、やや原理主義的な感じもしました。

カラムが増える場合はテーブル分割したほうが良い面もありますね。ただ1:1の構成になりますんで、非正規化は徹底されていないです。メリットデメリットをみることが大事カナと思います。

-Database, プログラミング全般

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

MySQLのLIMIT,OFFSETに関して&explainの見方など

自作のWEBアプリを作っていたところSELECT句が異常に遅いケースがありました。 発見までにかなり時間がかかったんですが、不可思議な現象としてはOFFSETが小さいときと大きいときで検索スピードが全 …

no image

オブジェクト指向 プレゼンテーション層

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日はプレゼンテーション層、いわゆるMVCのViewにあたる部分。 Contents1 プレゼンテーション層の考え方1.1 要点1. …

no image

slow-query-logについて

データベースを伴う部分でののチューニングですが、大きく分けると SQLを書き直す インデックスを張りなおす プログラム内部でキャッシュを有効化する 設定ファイルの修正 上記のようなかんじになるのではな …

no image

サロゲートキーと主キーに関して

今までも何度か触れたサロゲートキーと主キーに関して。 今までの参考リンク 論理設計のグレーノウハウ サロゲートキー サロゲートキーに関して 主にシステム設計的な考察が多かったので、今回はユースケースか …

no image

コードレビュー時のポイント

コードレビュー(仕様的な点ではなくて規約的なところのチェック)などで気をつけることなど。 ポイントとしては検知ツールで確認するコストを減らすことが一番大事(カスタマイズの方法について調べておく)、ある …

アーカイブ