5

私が理解しているように、ドキュメント指向のデータベースには構造化されていない情報を入力できます。次のようなドキュメントを想像してみましょう。

{
  name: 'John Blank',
  yearOfBirth: 1960
}

その後、新しいバージョンで、この構造は次のようにリファクタリングされます。

{
  firstname: 'John',
  lastname: 'Blank',
  yearOfBirth: 1960
}

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

4

1 に答える 1

3

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

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

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

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

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

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

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

于 2010-05-16T23:41:04.887 に答える