skillup

技術ブログ

Database

データベース設計のアンチパターン 重すぎるOLTP+Date型不統一+データ量想定が甘い

投稿日:

重すぎるOLTP

※OLTP=オンライントランザクションシステム(多数の端末から中央のデータベースにアクセスするタイプのシステム)

デメリット

速度を要求されるシステムなのに、遅いためユーザー離脱などにつながる。

対策

  • 早い段階でのプロトタイプでの性能確認(大量データでの性能確認)
  • 業務要件自体が無理
  • 非正規化
  • 実行計画での早期確認
  • 早い段階での集計表作成

DATE型の型の不統一

デメリット

規約が不十分なため、yyyymmddとyyyymmddhhmmssが混じるなど

対策

  • 規約の再定義
  • 時分秒があるときは00:00:00を入れると事故(意図した検索結果が出力されない)の元になる
  • 日付を検索するときは原則、時分秒までいれていいとおもう(個人的には。)
  • check制約を入れるのもあり
  • データベースだけではなく、画面表示なども混乱することが多い(ライブラリなどで統一した表記にしておいたほうがいいかも)

データ量の想定が甘い

デメリット

システム構築後数年たって、データ量が増えすぎ、パフォーマンスが劣化する

いざ削除しようと思っても、削除していいデータかどうかわからず削除ができない

対策

  • データ削除機能(物理削除)を持たせる
  • 概算値でいいので、データの蓄積量を決める
  • 設計段階でのCRUDの意識

-Database
-

執筆者:


comment

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

関連記事

no image

Postgresの基礎(主にMySQLとの違いなど)

えー来月(2020年3月)より、postgresを使うかもしれないので、ちょっと復習を。 Contents1 以前のリンク2 基本コマンド比較2.1 超頻出系3 テーブル比較4 SELECT文5 do …

no image

論理設計のグレーノウハウ 列持ちテーブル、集計キー、多段ビュー

前回に引き続き論理設計のグレーノウハウについて。 Contents1 列持ちテーブル1.1 メリット1.1.1 シンプルな設計1.1.2 入出力のフォーマットと合わせやすい1.2 デメリット1.2.1 …

no image

サブクエリ 応用編

本日も引き続きサブクエリです。 前回とちょっと近いですが、下記のような歯抜けのテーブル(sales2)があるとします。 year | sale ——+—&#8212 …

no image

データ構造の基礎知識 後編 木構造

データベースの学習をしていたときの復習です。 データ構造の基礎知識 前編 メモリとポインタ、配列と連結リスト データ構造の基礎知識 中編 ハッシュ 今回はもう少し複雑な「木構造」について考えてみます。 …

no image

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

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

アーカイブ