DBマイグレーションを行う技術 - 発明のための再発明
データベースのスキーマを変更するということはデータをいじる行為であり、最悪の場合データが消えます。 最悪の事態にはならなくとも、思わぬ場所に影響が起きたり、データの不整合が発生する恐怖と戦う必要が有ります。 テストや切り戻しを含めて計画し、大きな変更の場合にはダウンタイムまで考慮する必要があります。 そこで、RDBを対象にデータベースの変更を行う方法について書いていきます。 スキーマ変更 まずは、スキーマ変更について、 カラムを追加する 一番簡単で、影響も少ない変更です。 気をつけるのは、 ソースコードの変更よりも前にスキーマ変更を完了させる (長時間)ロックがかからない方法を選ぶ といったところでしょうか。 大抵の場合は、スキーマの変更とソースコードの変更の順番にさえ気をつければ問題は発生しません。 カラム名を変更する 「ALTER」でさくっと変えたくなりますが、ソースコードの変更が同時
DynamoDBデータモデリング虎の巻：第弐巻 〜考え方編〜 - misc.tech.notes
前巻のおさらい 前巻はDynamoDBのデータモデリングをする前に知っておいた方が良いDynamoDB自体の仕組みやデータ構造のお話でした。 marcy.hatenablog.com 今回は 今回はデータモデリングを行う際に必要なマインドセット、つまり「考え方」について書き記したいと思います。非常によく聞かれる「RDBとの考え方の違い」といった切り口で進めていきたいと思います。 RDBとはアプローチが真逆 RDBのデータモデリングをする場合、まず正規化されたデータのスキーマを決めることから始めると思います。慣れてくると律儀に第一正規化から始めずにいきなり第三正規形あたりから設計しだすことも多いと思います（私もそうです） そして、データのスキーマが決まってからそれに対してどのようにアクセスするか（＝SQL）をアプリケーションを設計する際に考えていくというのがRDBでの一般的なアプローチではな
論理型の設定値を RDB に保存する場合の選択肢と各々のメリット・デメリット
ユーザごとに特定の機能に対して ON/OFF の設定値を持たせることはよくあると思います。 RDB にそのような設定情報を持たせる場合の選択肢として大きく次の 5 つが考えるんじゃないかと思います。 設定項目ごとにカラムを割り当てる 設定項目ごとにレコードを割り当てる（追記：アンチパターンという意見があるので最後に補足を書きました） 設定項目ごとにテーブルを割り当てる（自分は思い付かなかった） 設定項目ごとに 1 つの整数型カラムの 1 bit を割り当てる 1 つのカラムに JSON 等で全ての設定情報を持たせる データベース理論的には 1, 2, 3 以外の選択肢はない気がしますが、実用上は 4, 5 も良い選択となることがあるので、メリット・デメリットを考えて選択する必要があると思います。 そんなわけで、それぞれの選択肢に関してメリット・デメリットを自分なりに考えてみました。 考慮す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
