skillup

技術ブログ

Database

アンチパターン データ分身の術+DBの不要な連携+バージョンアップ未テスト

投稿日:

今回のアンチパターンは主にデータ設計に関する部分。

同一データの使用

以前説明したアンチパターン「同一値を複数テーブルに配置」に少し近い。テーブルが無駄に分かれており、同一データ(とおもわれるもの)が複数テーブルにある。または意味不明な複数のテーブルが存在している。

デメリット

  • データ同士の同期が取れなくなり、いずれ差分が起こる
  • どのデータが正かがわからなくなる
  • 時間がたつにつれ複数のテーブルに同じ処理をしなければならないため、追加開発のコストが高くつく

対策

  • 時間がかかっても不要なデータ重複をなくしていく
  • 全体のデータモデル図を書く
  • 安易にこのデータをこちらにコピーみたいなことを行わない

DBの不要な連携

処理に必要なデータが別々のDBに散らばっているため、不要な連携が行われる。追加開発において、既存部分への変更を最小限にするために安易にDB連携を行ってしまうことが多い。

なお「同一データの使用」を避けるために、この手法がとられることもある(元のデータに変更を加えたくないため。)。

デメリット

  • SQLが非常に遅い(ネットワークの通信速度はメモリアクセスに比べてはるかに遅いため)
  • 他のデータベースの影響を受ける(あるDBが止まると自分も影響を受ける)。

対策

  • 時間をかけて再構築を行う

サーバーの移行やバージョンアップでSQLテストを行わない

バージョンアップによる不具合。データベース以外にも通常のアプリなどでもあるため、バージョンアップを甘く見ないこと

デメリット

  • SQLの遅延(実行計画はバージョンにより大きくかわるため)

対策

  • 開発環境にてバージョンアップを上げておく
  • 仮想環境ツールなどを有効に使うこと
  • 業務に影響度が大きいSQLをリストアップしておき、優先的にテストを行う

-Database
-

執筆者:


comment

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

関連記事

no image

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

Contents1 重すぎるOLTP1.1 デメリット1.2 対策2 DATE型の型の不統一2.1 デメリット2.2 対策3 データ量の想定が甘い3.1 デメリット3.2 対策 重すぎるOLTP ※O …

no image

CASE式のすすめ その2

本日も「達人に学ぶSQL徹底指南書」を地道に進めていきます。 Contents1 CASE式の利用2 UPDATE文のCASE3 テーブル同士のマッチング CASE式の利用 私自身はCHECK制約を使 …

no image

SQL基礎 case式について

case式に関して。 集約系の関数では複雑な処理を一気に行うことができる。 case式は1列のみ有効。複数の列に対して行うことはできない。 case ~ when ・・・thenではwhenが評価され …

no image

PostgreSQLについて

本日はポスグレ(PostgreSQL)について。 自分はほとんどMySQLだったので、主にMySQLとの比較について書いていきます。 Contents1 アーキテクチャの違い1.1 MySQL1.2 …

no image

ユニークキーの設定

MySQLでのユニークキーの設定に関して。 ユニークキーの設定は下記の通り。

ユニークキーを作成した後に確認するのは下記コマンドで。 …