0

ユーザーがカスタム フィールドを作成できるようにする必要があるアプリケーションを作成しています。これは、ドキュメント ベースの (基本的にはシリアル化された辞書) モデル フィールドに格納するのが最適だと思います。

これらの潜在的に非常に大きなドキュメントを SQL データベースに格納すると、パフォーマンスの問題が発生するのではないかと懸念しているため、ドキュメントを SQL データベースに格納する代わりに、ドキュメントへのポインターを SQL データベースに格納するだけでよいと考えました。ドキュメント自体は、別の NoSQL データベースに保存されます。

この構造が理にかなっていると仮定すると、この方法でカスタム データ フィールドを格納するフィールドを構築するための最良の方法は何ですか? これらのカスタム フィールドは、オブジェクト上で属性としてアクセス可能であり、名前に「_c」が追加されたカスタムとして示されることが最適です。たとえば、django モデル オブジェクトでは、created_date は created_date_c になります。これに取り組むにはカスタムマネージャーが最適だと思います: https://docs.djangoproject.com/en/dev/topics/db/managers/

編集: 私の SQL データベースは MySQL です。また、ドキュメントは列としてより意味のあるものになる可能性があります (Cassandra などの場合)。これについての考えは役に立ちます。

4

1 に答える 1

1

私の知る限り、このタスクに最適なアプローチはありませんが、長所と短所がある他の 2 つのオプションを検討することをお勧めします。

  • ユーザー定義データをJSONfieldまたはpickled fieldに保存します。これにより、カスタム マネージャーと NoSQL を作成する際の多くの労力を節約できます。固定構造データと一緒に保存するのが心配な場合は、たとえば別のInnoDB ファイルに 1 対 1 の関係で別のモデルに保存してください。

  • ユーザーデータを一般化された(field_id, field_name, content_type)辞書(object_id, field_id, field_value)に保存します。これらは、フィールド タイプ ( 、 など) で分割intできますstring。floatこのアプローチでは、データ モデルを最初から適切に実行できるわけではありませんが、スマートなインデックス作成とパーティショニングは注目に値します。そして、データクエリ、モデル構造の強制は、他のアプローチよりもはるかに簡単になります.

  • 変更可能なコンテンツに NoSQL またはその他のデータベースを使用することを検討している場合は、データの効率的なクエリを実行できる手段を備えたものを必ず選択してください。このディスカッションとwikiを参照してください。

于 2013-11-05T09:12:05.787 に答える