ドキュメント指向データベース-ドキュメント定義が変更された場合はどうなりますか？

Question

私が理解しているように、非構造化情報はドキュメント指向データベースに入力できます。このようなドキュメントを想像してみましょう： ジェネラコディセタグプレ

後で、新しいバージョンでは、この構造はリファクタリングされます ジェネラコディセタグプレ

ドキュメント指向データベースでこれをどのように行いますか？データベース内のすべてのエントリを変更するマージスクリプトを準備する必要がありますか？または、構造の変更を処理するためのより良い方法はありますか？

Answer 1

ここでのリファクタリングは、古いスキーマから新しいスキーマへの決定論的なマッピングがあることを意味します。したがって、最も効果的なオプションは、SQLデータベースで行うのと同じことを行い、実際にドキュメントを更新することです。

ドキュメント指向データベースには、もう1つのオプションがありますが、それはどのDODBと、フロントエンドでの使用方法によって異なります。そのオプションは、単にデータをそのままにして、一種の下位互換性オプションとしてアプリケーションで「古い」定義をサポートすることです。つまり、永続的な1回限りの更新ではなく、これらの翻訳をオンザフライで実行します。

これはSQLデータベースのオプションではありません。これは、廃止された列を保持し、場合によってはインデックスを作成する必要があるためです。 DODBを使用すると、データやインデックススペースを実際に無駄にすることはありません。メリットとデメリットを比較検討する必要があります。

主な欠点は、明らかに一貫性がないことです。これは時間の経過とともに大きくなり、バグにつながる可能性があります。もう1つの欠点は、これをオンザフライで実行するための計算コスト、または新しい構造を効果的に使用できないことです（たとえば、lastnameだけでインデックスを作成したい場合があります）。そのため、ほとんどの場合、一括更新を実行することを選択すると思います。

ただし、古いドキュメントを保存することには明らかな利点が1つあります。リファクタリングが完全であるかどうかわからない場合-たとえば、name列のデータが一貫した規則に従わなかった場合、場合によってはlastname, firstnameであり、他の場合ではfirstname lastnameであり、他の場合はcompany nameです-永続的な更新を行わずにオンザフライで変換を行うと、時間の経過とともにマッピングを調整できるため、利用可能な場合はfirstnameフィールドとlastnameフィールドを使用できますが、レガシーデータのname推測ゲームにフォールバックできます。

前述のように、すべてのレコード/ドキュメントに対して正しい「リファクタリング」を取得できると確信できない例外的なケースのために、おそらく2番目のオプションを予約します。それでも、他の種類のデータベースでは実際には利用できないオプションです。

これら2つを除いて、他に明確な代替案はありません。それは一種の二者択一の決定です。既存のデータを永続的に更新するか、更新しないかのどちらかです。