2020年目標

2020年目標

2019年の振り返り+個人的に取り組みたいことから今年の目標として下記を設定。

目標①:実務に役立つ資格を2つ取る

数値目標:データベーススペシャリスト&医療情報技師の合格

  • 自分で学びたいと思う分野は実務に離れた内容が多い。
  • 実務に直結する内容を学びつつ、結果も明確なため資格試験を受ける。
  • データベーススペシャリストは4月、医療情報技師は8月なので、上期は殆ど試験勉強で埋まる予定。

目標②:ブログにアウトプットする

数値目標:8記事(資格試験(2記事)+読んだ本の感想(6記事))

  • 目標①の勉強内容や所感を2記事書く。
  • 前年実績だと月平均約1.5冊の本を読んでいた。
  • 8月までは試験勉強で本を読めないと思うので、9月~12月の4ヶ月×前年実績で目標を設定。

目標③:社外のエンジニアと交流する

数値目標:4回

  • 昨年は社外のエンジニアの方と話す機会があり、とても刺激を貰えた。
  • (家庭の事情でなかなか自由な時間は取れないかもしれないが、)四半期に一度は社外の方と交流し良い刺激を貰う。

2019年振り返り

2019年振り返り

今年の目標と実績

振り返る前に、まずは新年に立てた目標に対して予実を確認する。

No 内容 目標 実績 補足
1 ブログ更新の単位を週ではなく成果レベルに切り替える。 8記事 7記事 写経してみた系の記事(7記事))+自作Webサービスについての記事(1記事)
2 朝活のように手を動かす必要がない本を読んだ場合でもアウトプットする。 5記事 17記事 写経しない本を読んだまとめ記事(17記事)
3 土日も自己研鑽の時間を少しでも取る。 5時間/月 ?? 時間は測れていない問題はあるが、月平均5時間以上は間違いなく本を読めた。

今年の振り返り

  • Keep
    • 出張や有休以外の平日は朝活できた。(193日活動できた。)
    • 目標の3倍を超える本を読むことができ、本を読む習慣化が出来た。
    • 5月からGoogleAnalyticsを導入することで月当たりのPVが分かるようになった。(はてなブログだけだと、先月のPVが分からなかった。)
    • Web開発素人でもFirebase+Vue.jsで在席管理サービスが作れた。とても勉強になった。
    • 社外のエンジニアの方と話す機会があり、良い刺激を貰えた。
  • Problem
    • 目標の3つ目は実績が測りづらい目標にしてしまった。
    • 通勤に時間がかかるようになり、手を動かす朝活の量が減った。(その分本は読めるが…)
    • 会社での朝活中に声を掛けられ、作業が中断することがあった。
    • PVを取るようにしたが、本当にジワジワとしかPVが増えない。
    • 社内の自己研鑽をする意識の高い人達が辞めたり別の部署に移動したりし、モチベーションを高められる環境が減ってしまった。
  • Try
    • 来年度は計測が出来るような目標を立てる。
    • 本を読む以上に得られるものがあるため、自作のアプリを何かしら作る。
    • 引き続き本を読む週間は続ける。
    • 刺激をもらえるよう社外のエンジニアと会う。
    • 来年は今年よりPVをどれだけ上げるか目標を立てて取り組む。

今年の振り返り結果を反映した目標を立てよう。

「SQLアンチパターン」を読んで【第Ⅳ部】

書籍

SQLアンチパターン

SQLアンチパターン

はじめに

読んだ書籍は1記事にまとめると文量が多くなるため、導入+各部ごとの記事としてまとめる。

本記事は「第Ⅳ部:アプリケーション開発のアンチパターン」になる。その他の部についての記事は下記参照。

印象に残った点

※ 下記のカッコ書きは該当する章番号。

リーダブルパスワード(読み取り可能パスワード)[19]

- 目的:パスワードのリカバリーとリセットを行う
- アンチパターン:パスワードを平文で格納する
- アンチパターンを用いてもよい場合
  - 少人数が使うイントラネットのアプリケーション
- 解決策:ソルトを付けてパスワードハッシュを格納する
  • 前に読んだ本も認証のためにソルト使ってた。ソルトを使うことが最低ラインなのかもしれない。
  • パスワードのハッシュ化はなるべくユーザに近い箇所でやるべきなのか。その通りだと思った。

SQLインジェクション[20]

- 目的:動的SQLを記述する
- アンチパターン:未検証の入力をコードとして実行する
- アンチパターンを用いてもよい場合
  - 正当化する理由はない
- 解決策:誰も信用してはならない
  - 状況に応じて以下技法を適切に使い分ける
    - 入力のフィルタリング(無効な値を事前除去)
    - プリペアドステートメントを用いる
    - 動的値を引用符で囲む
    - ユーザの入力をコードから隔離する(マッピングする)
    - レビューしてもらう
  • プリペアドステートメントだけで良いと思っていたがそれだけでは駄目なのか。
    • 状況に応じ、入力値のフィルタリングやマッピングなど様々な引き出しを使えるようにならないといけないなぁ。
  • レビューも効果的に使う必要があるのか。それなりのスキルがないと効果的なレビューにならないなぁ。

シュードキー・ニートフリーク(疑似キー潔癖症)[21]

- 目的:欠番を詰める
- アンチパターン:隙間を埋める
  - 欠番を埋める(欠番を探すクエリは不要な自己結合が必要)
  - 既存行に番号を振り直す(Updateするため競合状態を引き起こしやすい)
- アンチパターンを用いてもよい場合
  - 正当化する理由はない
- 解決策:疑似キーの欠番を埋めない
  - 疑似キーは行番号ではないため連続している必要はない
  - GUIDを使用する
  - 上司を管理する(技術やコストについて説明)
  • 疑似キーはあくまで擬似的なキーなのに欠番を埋める意味ある?と思っていたが、解決策は自分の考えと同じだった。
    • 行番号と同じだと思う人もいることを認識しておかないといけないなぁ。
  • GUID使えるベンダー製品あるのか!!GUIDであれば欠番を意識することないのでメリットもあるなぁ。

シー・ノー・エビル(臭いものに蓋)[22]

- 目的:簡潔なコードを書く
- アンチパターン:肝心な部分を見逃す
  - 戻り値を無視する
  - 実行するクエリをログ等に残さない
- アンチパターンを用いてもよい場合
  - close関数でエラーを返してもその後アプリが終了する
  - 処理の責任がないので例外を無視する
- 解決策:エラーから優雅に回復する
  - 戻り値と例外をチェックする
  - 実際に構築されたSQLクエリを出力する
  • これは当たり前にやってるのでは?と思った。戻り値や例外を握り潰すのはアカンでしょ。
  • 昔保守していた製品はSQLクエリをログに出していなかったので調査が辛かったことを思い出した。痛みを知ってるから当たり前と思っているのかもしれない。

プログラマティック・イミュニティ(外交特権)[23]

- 目的:ベストプラクティスを採用する
- アンチパターン:SQLを特別扱いする
  - アプリケーション開発のルールをデータベース開発に当てはめない
- アンチパターンを用いてもよい場合
  - 1度きりの利用だと割り切れる(利用したら躊躇わず消せる)
- 解決策:包括的に品質問題に取り組む
  - 文書化/バージョン管理/テスティングを行う
  • アプリケーションコードの文書化の価値は低いが、データベースの文書化には価値があると述べる人達もいるのか。
    • 今保守している製品はこの考えに近い。アプリ観点であればアンチパターンになるケースは少ない気がする。
  • StackOverflowのPodcastあるのか!知らなかった。
  • テーブル定義はバージョン管理しているけど、ER図や関連の説明が弱いんだよなぁ。やっぱ欲しいよなぁ。
  • DBに関するテストもやるのか。確かにやったほうが良い。

マジックビーンズ(魔法の豆)[24]

- 目的:MVCのMを単純化する
- アンチパターン:モデルがアクティブレコード(魔法の豆)そのもの
  - アクティブレコードはモデルをデータベーススキーマに強く依存させてしまう
  - アクティブレコードはCRUD機能を公開してしまう
- アンチパターンを用いてもよい場合
  - テーブルの各行を操作するだけのシンプルなアプリ
  - 素早くコードを書くプロトタイプ作成(技術的負債を生むリスクはある)
- 解決策:モデルがアクティブレコードを「持つ」ようにする
  - ドメインモデルの使用(DB操作をモデルクラスに完全に隠蔽する)
  • アクティブレコードはシンプルなアプリであれば良いが、複数のテーブルを使うとなるとスパゲティ化してしまうリスクは確かにありそう。
  • ドメインモデリングの能力も高めたくなった。

砂の城[25]

- 目的:サービスの安定稼働
- アンチパターン:想定不足
- アンチパターンを用いてもよい場合
  - コストとのトレードオフで許容する
- 解決策:トラブルを「当然起きる日常的なもの」として捉える
  - ベンチマークを取る
  - テスト環境を用意しておく
  - 適切な例外処理を実装する
  - バックアップを取る
  - ディザスタリカバリを考慮する
  - 運用ポリシーの作成
  • 問題かサービスへ及ぼす影響が軽微であれば、自動的にトランザクションをリトライして問題を無視することも視野に入れることは大事なのかもしれない。
    • 保守していて思うのは、全てを完璧にする(=何も問題がない)ことは不可能だと感じるので、重要度に応じた対応を意識したい。
  • リスクマネジメントをちゃんとやりましょう!ということだろう。リスクの想定が甘いと問題になりますよね…

「SQLアンチパターン」を読んで【第Ⅲ部】

書籍

SQLアンチパターン

SQLアンチパターン

はじめに

読んだ書籍は1記事にまとめると文量が多くなるため、導入+各部ごとの記事としてまとめる。

本記事は「第Ⅲ部:クエリのアンチパターン」になる。その他の部についての記事は下記参照。

印象に残った点

※ 下記のカッコ書きは該当する章番号。

フィア・オブ・ジ・アンノウン(恐怖のunknown)[13]

- 目的:欠けている値を区別する
- アンチパターン:NULLを一般値として使う、または一般値をNULLとして使う
- アンチパターンを用いてもよい場合
  - 外部データの入出力
  - 欠けている値の区別
- 解決策:NULLを一意な値として使う
  • SQLの3値論理の振る舞いを理解していれば迷うことはない。ただ3値理論だと知らなかったらハマるのは分かる。
  • IS DISTINCT FROM便利だなぁ。対応していない製品もあるのか。

アンビギュアスグループ(曖昧なグループ)[14]

- 目的:グループ内で最大値を持つ行を取得する
- アンチパターン:非グループ化列を参照する
- アンチパターンを用いてもよい場合
  - 関数従属性を用いてクエリ結果の曖昧性をなくせる場合
- 解決策:曖昧でない列を使用する
  - 関数従属性のある列のみにクエリを実行する
  - 相関サブクエリを使用する
  - 導出テーブルを使用する
  - 他の列に対しても集約関数を使用する
  • 単一値の原則か。普段利用しているDBMSだとエラーが出るためあまり意識していなかった。違う製品使っていたら危なかったかも。

ランダムセレクション[15]

- 目的:サンプル行をフェッチする
- アンチパターン:データをランダムにソートする
- アンチパターンを用いてもよい場合
  - データセットが小さく、大きくなる増える可能性もない場合
- 解決策:特定の順番に依存しない
  - ランダムなキー値を選択する
  - アプリケーションコードで対応する
  - ベンダー依存の解決策を使う
  • ランダムな値を業務上使う事がなかったのでなるほど。と思うところが多かった。インデックスが効くかどうかを常に意識することが鍵だなぁ。
  • ベンダー依存の解決策は製品間の移行を考えなければ良い解決策だと感じた。

プアマンズ・サーチエンジン(貧者のサーチエンジン)[16]

- 目的:全文検索を行う
- アンチパターン:パターンマッチ述語を使用する
- アンチパターンを用いてもよい場合
  - シンプルな用途や使用頻度が低い場合
- 解決策:適切なツールを使用する
  - ベンダー拡張機能を使用する
  - サードパーティのサーチエンジンを使用する
  - 転置インデックスを自作する

スパゲッティクエリ[17]

- 目的:SQLクエリの数を減らす
- アンチパターン:複雑な問題をワンステップで解決しようとする
  - デカルト積が発生し想定外の結果になる場合がある
- アンチパターンを用いてもよい場合
  - 単一SQLクエリを前提とするコンポーネントやレポートツールを利用している場合
  - 複数の結果を1つのソート順で表示させたい場合
- 解決策:分割統治を行う
  - ワンステップずつ
  - UNIONを使う
  - SQLを用いてSQLの自動記述する
  • 複雑なSQLをメンテするのは本当に辛いので分割統治は保守観点からみてもとてもありがたい。
  • SQLの結果にSQL文を出力させるのか。そういう考えはなかった!実務でも使えそう!
  • デカルト積とは何ぞや?と思ったが、結合のベースとなる考えとのこと。
    • 抽出条件によって制限をかけないとデカルト積になるのか。なるほど。(参考)

インプリシットカラム(暗黙の列)[18]

- 目的:タイプ数を減らす
- アンチパターン:ショートカットの罠に陥る
  - ワイルドカードや暗黙的な列指定によってタイプ数を減らすも、リファクタリングや帯域の使いすぎになる
- アンチパターンを用いてもよい場合
  - アドホックなSQL
  - 開発時の効率や可読性の向上をトレードオフしてでも採用したい場合
- 解決策:列名を明示的に指定する
  • ワイルドカードを使うクエリの代償は考えてなかった。誤りの防止やスループットの抑制のためにも明示したほうが良い。
  • ワイルドカードの例を袋の飴(袋に入った飴を買っても飴を食べるときは最終的には取り出さないといけない)に例えており、秀逸だなぁーと感じた。全くもってその通り。

「SQLアンチパターン」を読んで【第Ⅱ部】

書籍

SQLアンチパターン

SQLアンチパターン

はじめに

読んだ書籍は1記事にまとめると文量が多くなるため、導入+各部ごとの記事としてまとめる。

本記事は「第Ⅱ部:データベース物理設計のアンチパターン」になる。その他の部についての記事は下記参照。

印象に残った点

※ 下記のカッコ書きは該当する章番号。

ラウンディングエラー(丸め誤差)[9]

- 目的:整数の代わりに小数値を使用する
- アンチパターン:FLOATデータ型を使用する
  - 丸めが避けられない
  - 浮動小数点数の誤差累積がでる
- アンチパターンを用いてもよい場合
  - 科学技術計算を行うアプリケーション
- 解決策:NUMERICデータ型を使用する
  - 精度とスケールを指定し固定精度の小数点数を表現する
  • 保守している製品は計算に利用する値を一旦文字列型データとしてDBに入れ、アプリ側で利用する際は数値に戻して計算することが多い。SQLを使った計算をすることがなければそれで良いのかもしれない。

サーティーワンフレーバー(31のフレーバー)[10]

- 目的:列を特定の値に限定する
- アンチパターン:限定する値を列定義で指定する
  - 限定する値の取得が難しい
  - 値の追加や削除が手間
  - CHECK制約がDBMSによって異なるため移植が困難
- アンチパターンを用いてもよい場合
  - 相互排他的な2つの値(例:左/右、有効/無効)
- 解決策:限定する値をデータで指定する
  - 限定する値の参照テーブルを用意し、外部キー制約で参照する
  • CHECK制約を使うタイミングは気をつけないといけないなぁ。この本を読めば読むほど保守している製品のDBの使い方がユルユルだと感じる。

ファントムファイル(幻のファイル)[11]

- 目的:画像をはじめとする大容量メディアファイルを格納する
- アンチパターン:物理ファイルの使用を必須と思い込む
  - レコード削除時にファイルが連動して消えない
  - ロールバックしてもファイルが消えない
  - SQLのアクセス権と外部ファイルのアクセス権が一致しない
  - レコードにある画像パスが正しいとは限らない
- アンチパターンを用いてもよい場合
  - DBの容量を減らしたい
  - バックアップを短時間で終わらせたい
  - 画像ファイルの編集やプレビューを容易にしたい
- 解決策:必要に応じてBLOB型を採用する
  • 保守している製品は外部ファイルを用いているが、運用を考えるとアンチパターン採用した判断には賛成できる。
  • SQL Server 2008にはFILESTREAMという型があるのか。実際に利用している記事があまり見つからなかった。(使い方紹介が多い。)

インデックスショットガン(闇雲ショットガン)[12]

- 目的:パフォーマンスを最適化する
- アンチパターン:闇雲にインデックスを使用する
  - そもそもインデックスを利用しない
  - インデックスを多くを定義し過ぎる
- アンチパターンを用いてもよい場合
  - なし(情報を集め検討することが必要)
- 解決策:「MENTOR」の原則に基づいて効果的なインデックス管理を行う
  - Measure(測定):クエリのパフォーマンスを測る
  - Explain(解析):クエリの処理が遅くなる原因を解析する
  - Nominate(指名):インデックスを使わないでアクセスしている箇所を特定する
  - Test(テスト):変更による効果を確認する
  - Optimize(最適化):キャッシュサイズを最適化する
  - Rebuild(再構築):不均衡なインデックスを整える
  • インデックスの効果を最大限に活かすためには各製品の詳しい知識が必要となるのか。一般的な知識だけでは十分ではないのか。
  • カバーリングインデックスという存在を知った。本を読んだだけではイメージしづらかったが、こちらを見ると理解出来た。
    • なるほど、こりゃ速くなりそう。

「SQLアンチパターン」を読んで【導入】

書籍

SQLアンチパターン

SQLアンチパターン

はじめに

読んだ書籍は1記事にまとめると文量が多くなるため、導入+各部ごとの記事としてまとめる。

本記事は「導入」になる。その他の部についての記事は下記参照。

この本を選んだ理由

  • RDBをより深く学びたい為。
  • 尊敬する先輩がオススメしていた為。

この本の対象読者

  • DBを使った製品開発の経験がある人。
    • 製品開発経験があると、自分の経験と照らし合わせて「分かるわぁ…」とあるあるネタを共感できて良い。
    • 製品開発経験がないと、「ふーん、そういう事あるんだ…」で終わってしまう可能性がある。

所感&今後

  • 章の数は多いものの、各章のボリュームが少ない&構成が決まっておりとても読みやすい。
    • ここまで読みやすい専門書は他にあったかな?と思うくらい良くまとまっている。
  • DBって面白い。DBスペシャリストの試験受けてみよう。
  • DBの仕組みをより深く知りたい気持ちが強くなった。より深く学べる本を探して読んでみたい。

「SQLアンチパターン」を読んで【第Ⅰ部】

書籍

SQLアンチパターン

SQLアンチパターン

はじめに

読んだ書籍は1記事にまとめると文量が多くなるため、導入+各部ごとの記事としてまとめる。

本記事は「第Ⅰ部:データベース論理設計のアンチパターン」になる。その他の部についての記事は下記参照。

印象に残った点

※ 下記のカッコ書きは該当する章番号。

ジェイウォーク(信号無視)[1]

- 目的:複数の値を持つ属性を格納する
- アンチパターン:カンマ区切りフォーマットリストを格納する
  - 検索時にパターンマッチが必要になりインデックスが効かない
  - アカウント更新/削除が辛い
  - アカウントIDの妥当性検証ができない
  - 区切り文字の選択が難しい
  - リストの長さに制限があり設計根拠に欠ける
- アンチパターンを用いてもよい場合
  - 非正規化によるパフォーマンス向上
  - カンマ区切りのデータが必要
- 解決策:交差テーブルを作成する
  • 今携わっている製品でカンマ区切りでデータを入れている箇所がある。アンチパターンのツライ点を見ても思い当たりそうなのは内容の妥当性検証くらい。メリットはテーブルを減らすことだろう。
    • 設計した方はメリットデメリットを考えてこの方法を選んだのかもしれない。

ナイーブツリー(素朴な木)[2]

- 目的:階層構造を格納&クエリを実行する
- アンチパターン:常に親のみに依存する(隣接リスト)
  - 階層を深くする度にJOINが必要
  - ノード更新が非常に手間
- アンチパターンを用いてもよい場合
  - DBMSで再帰クエリがある
- 解決策:経路列挙/入れ子集合/閉包テーブル
  - メリットデメリットがあるので考慮して採用する
  • 実務でツリー構造を取り扱ってはいないため、フムフム。そういう方法もあるのか。というコメントくらい。
  • ツリー構造部分だけNoSQLでは駄目なのかな?と思い調べると同じ質問をされている方がおり、「RDBでもツリー構造は実装できるし、ツリー構造だけのためにNoSQLを採用するのはコストが高い。」と書かれていた。確かにそうだ。

IDリクワイアド(とりあえずID)[3]

- 目的:主キーの規約を確立する
- アンチパターン:すべてのテーブルに「id」列を用いる
  - 冗長なキーが作成されてしまう(規約を重視して自然な主キーを無視する)
  - 重複行を許可してしまう(交差テーブルにidを用いる)
  - キーの意味がわかりにくくなる
  - すべて「id」にするとUSINGを使用できない
  - 複合キーは使いにくい
- アンチパターンを用いてもよい場合
  - ORMフレームワークの規約に従う
  - 疑似キーや主キーがあまりにも長くなる
- 解決策:状況に応じて適切に調整する
  - idではなく分かりやすい名前にしたり、自然キーや複合キーを採用する
  • 実務のテーブル設計ではidの名前には気をつけていると思う。ただ、自然キーを用いれるところもあると思うがidにした経緯が分からないところもある。
  • 実務のシステムでは採番テーブルを使いシーケンス番号を振っているが明らかに無駄。DBMSにて提供されている機能を使えば良いのにと思う。

キーレスエントリー(外部キー嫌い)[4]

- 目的:データベースのアーキテクチャを単純化する
- アンチパターン:外部キー制約を使用しない
  - 完璧なコードが前提となる
  - 参照性の不整合ミスを調べなければならない
- アンチパターンを用いてもよい場合
  - 外部キー制約をサポートしていないDBMSを利用している
  - 極端に柔軟なデータベース設計を扱わないといけない
    - 参照整合性制約を使えないとその他のアンチパターンに陥る可能性が高い
- 解決策:外部キー制約を宣言する
  - カスケード更新により複数テーブルの更新が可能になる
  - 事前のselectやテーブルロックが不要になる
  - 孤立したデータが生じない
  • 保守している製品は外部キー制約が使えるにも関わらず使っていない。設計真意は不明だが、孤立したレコードができたり、ガチガチにロックしたり、事前selectしたりしている。
    • DB設計によってアプリ側の苦労が減るのではと感じた。

EAV(エンティティ・アトリビュート・バリュー)[5]

- 目的:可変属性をサポートする
- アンチパターン:汎用的な属性テーブルを使用する
  - 属性の取得が冗長になる
  - DBが持つ整合性が利用できない
(必須の制約がもてない、データ型を使えない、参照整合性を強制できない)
  - 行の再構築が必要
- アンチパターンを用いてもよい場合
  - RDBの長所を失うため正当化出来る理由は簡単にない
  - 非リレーショナルな管理が必要であればNoSQLを使うべき
- 解決策:サブタイプのモデリングを行う
  - シングルテーブル継承:1つのテーブルで全て管理
  - 具象テーブル継承:共有属性込でサブタイプごとに管理
  - クラステーブル継承:サブタイプ固有属性+基底テーブルの外部キーで管理
  - 半構造化データ:1つのフィールドにサブタイプ固有の値を半構造化データ入れて管理
  • 保守している製品はEAVは使っていないが、フィールド名にcodeとdataを用意し、セットされるcodeに応じdataの意味が変わるようにデータを保存している。参照整合性の問題やフィールドを見ただけでは何のデータか分からないという問題がある。
    • うーん、RDBの良さを使っていないのは間違いない。

ポリモーフィック関連[6]

- 目的:複数の親テーブルを参照する
- アンチパターン:二重目的の外部キーを使用する
  - ポリモーフィック関連を定義する(メタデータの混入)
- アンチパターンを用いてもよい場合
  - ORMフレームワークを用いている
- 解決策:関連(リレーションシップ)を単純化する
  - 参照を逆にする
  - 交差テーブルを作成する
  - 共通の親テーブルを作成する
  • 保守している製品はポリモーフィック関連はない認識だが、メタデータの混入は多々存在する。RDBのメリットを使わない設計思想になっている。
    • 設計した人はいないし、資料もないので永遠に分からないだろう。

マルチカラムアトリビュート(複数列属性)[7]

- 目的:複数の値を持つ属性を格納する
- アンチパターン:複数の列を定義する
  - 値の検索/追加/削除が辛い
  - 一意性の保証が出来ない
  - フィールド追加の影響が大きい
- アンチパターンを用いてもよい場合
  - 列の順番に意味を持たせる
- 解決策:従属テーブルを作成する
  • 同じ意味を持つ値を格納するために複数の列を定義すべきではないことは分かった。
    • 汎用的な列を用意し、行ごとに列の使い方が異なるのはどうなんだろうか?この話とはちょっと意味合いが違うから、悪い設計ではないのか?デメリットはフィールド名が分かり辛いことぐらい?

メタデータドリブル(メタデータ大増殖)[8]

- 目的:スケーラビリティを高める
- アンチパターン:テーブルや列をコピーする
  - テーブル/列が増殖する(年毎にテーブルが出来る)
  - データの整合性管理が必要になる
  - テーブルが分割されると外部キーを使えない
- アンチパターンを用いてもよい場合
  - 現在と過去のデータを合わせてクエリ実行をする必要がない場合
- 解決策:パーティショニングと正規化を行う
  - 水平パーティショニングの使用
  - 垂直パーティショニングの使用
  - 従属テーブルの導入
  • 主要なDBMSはパーティショニングできるのか…。使ってみたい。
    • 保守している製品は15年くらいのデータが蓄積されている場合もあるので、必要になってくると思う。