skillup

技術ブログ

Database アーキテクト設計全般

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

投稿日:2017年7月25日 更新日:

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

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

データべース層

要点

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

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

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

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

対策

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

感想

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

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

-Database, アーキテクト設計全般

執筆者:


comment

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

関連記事

no image

SQL基礎 条件式はunionよりもcaseで

複雑な条件式があったときにcase式を使うことでパフォーマンスを向上させることができます。 ※一般にunionを使うよりも高速なことが多い。 例1 ある条件により別の列を使いたいとき、 [crayon …

no image

DB負荷調査のセオリー

DB負荷などで見ておきたいことのまとめなど。(今のプロジェクトではSQLServerを使っていますが、他のデータベースでも同じかと思います。) 参考URL SQLServer: 現在実行中クエリのリア …

no image

大規模Webサービス技術入門 DBの分散

前回に引き続き、大規模サービスを運用するときに必要になるMySQLの知識についてのまとめ Contents1 テーブル・SQL設計2 レプリケーション機能3 パーティショニング テーブル・SQL設計 …

no image

ロック(排他制御)について

ECなどでの開発の場合、当然在庫数によって購入できるか、いなかがかわってきますが、複数人で同時にアクセスする際、処理の整合性を見る必要がでてきますので、ロックのが概念が大事になってきます。 そこでロッ …

no image

サブクエリの使い方

以前も少し学習しましたが、今回からはサブクエリの扱い方です。特に異なった行の比較(年度計算など)に関して行われる自己結合をつかったものが非常に強力です。 例によってここを学習しています。 下記のような …

アーカイブ