データベーススキーマの移行は、運用環境で問題になりますか？
NoSQLとSQLデータベースについての議論で、スキーマを新しいバージョンに移行することが問題になるため、企業がスキーマレスNoSQLデータベースを使用することを好むと聞くことがあります。しかし、アップグレードを行うとき、それは本当に大きな問題ですか？リレーショナルデータベースは、このような操作に適していませんか？
MongoDBブログでこのブログ投稿を読みました： Why Schemaless？
NoSqlデータベースに従来の意味でのスキーマがないからといって、変化するときに処理する必要のある論理スキーマがないというわけではありません。 MongoDbを使用する典型的なアプリの場合、おそらくコードはjsonオブジェクトの特定のフィールドが特定の方法で動作することを期待しています。動作を変更すると、データベース内の既存のデータを更新する必要がある場合があります。これで、従来のRDBMSでは、これは大幅に解決された問題でした-基礎となるテーブルを変更するだけで済みました。しかし、これらの新しいNoSQLデータベースを使用して、あなたには決断があります-すべてのオブジェクトを変更して更新するスクリプトを作成しますか？または、バージョンをその場で変換するコードを追加しますか？もしそうなら、どのくらいの期間v1オブジェクトをサポートしますか？永遠に？ v3まで？
MongoDbブログの投稿で使用されている例は少し単純化されており、RDBMSが何であっても適切な更新プロセスがある場合に処理するのが非常に簡単であることを付け加えます。フィールドを追加してもほとんど問題はありません。 NameフィールドをFirstNameとLastNameに分割することを決定したとき、物事はエキサイティングになります。
しかし、アップグレードを行うとき、それは本当に大きな問題ですか？
かもね。
一部の組織は-まあ-組織化されておらず、スキーマ移行の非常に悪い仕事をしています。
「移行ウィークエンド」。サーバーを停止します。すべてのデータをバックアップしてエクスポートします。新しいスキーマを作成します（多くの場合、既存のスキーマを変更して）。データを再ロードするか、所定の位置に再構築してください。
「継続的な微調整」。 SQLで許可されている範囲でテーブルを変更します。実行されたALTERのシーケンスを追跡しません。以前のスキーマバージョンに戻る方法はありません。必要に応じて、既存のテーブルから新しいテーブルを作成し、うまくいけば、新しいテーブルを使用するようにすべてのアプリケーションを調整します。しかし-良いQAがない-念のために古いテーブルをそのままにしておく。
「フルパニック」。スキーマの変更を防止するだけです。大きな悪臭を放ちます。リスクが高すぎると主張します。この方向へのすべての努力を阻止してください。より賢明なアプローチを採用せざるを得なくなるまで、スキーマの人質を取りなさい。
リレーショナルデータベースは、このような操作に適していませんか？
スキーマを移行するのは面倒です。
最大の問題は技術的なものではありません。
それは意味です。
スキーマを変更する主な理由の1つは、以前のスキーマが問題のドメインとあまり一致しないことです。セマンティクスが変更されたため、データベース（およびアプリケーション）を変更する必要があります。これらは、アプリケーションがデータを処理する方法を再考する必要がある重大な変更である場合があります。
データベースのセマンティクスを修正することは非常に難しい場合があります。
スキーマの変更の代わりに人々が行うことは、単に物理スキーマを誤用することです。可能であれば、既存のフィールドに間違ったデータをロードし始めます。 「コメント」フィールドは突然、重要な顧客管理情報の後に「//」が続き、その後に実際のコメントが続きます。これは、「フィールド1-フィールド2 //コメント」というデータにまで成長します。 「実際の」アプリケーションソフトウェアには変更が難しいスキーマがあり、ITが変更を拒否したため、ユーザーはコメントフィールドからこの追加データを抽出するスプレッドシートを持っています。
テーブルと（null可能）列を追加する運用データベースを問題なくアップグレードします。アプリケーションの以前のバージョンは、アップグレードされたデータベースで正常に動作しますが、新しいものを参照しません。テーブルや列を削除したり、既存のデータの保存方法を変更したりすることは避けますが、必要な場合は適切な変換スクリプトを作成します。データベースにタイプセーフスキーマが宣言されているかどうかに関係なく、データ構造の変更には、新しい構造と対話するためのデータ変換とアプリケーションのアップグレードが必要です。
場合によります。
まず、複数のマシンにまたがる非常に大きなデータベースがある場合、（データベースの更新だけでなく）すべてが困難になります。 （事前にいくら計画していても）。
第二に、データベースの更新は単なるデータベースのことではなく、DBが含まれるより大きなシステムにも依存します。これには、データベースの展開（多くのデータベースサーバー、複数のデータセンター、マスター/スレーブセットアップなど）も含まれます。
システムコンポーネントを設計して、DBスキーマ変更イベントを何らかの「認識」するようにシステムコンポーネントを設計することで、痛みを軽減できます。これは、システム全体がスキーマの変更を許容し、「正常」な方法でそれに対応できることを意味します。
MySQLスキーマの更新に取り組むための Facebookによって開発されたユーティリティ を確認できます。
また、マスターを読み取り専用にする、スレーブに変更を加える、開発コピーを変更するなど、標準的なベストプラクティスもあります。
いずれにせよ、フルバックアップおよび広範囲テストスイートを使用することは、必須。そうして初めて、自信を持って安全に変更を行うことができます。