1

私はかなりの研究を行ってきましたが、一般的なコンセンサスは、可能な限りDBでシリアライズされたハッシュを避けることですが、私が持っている設計はこの構造に適しているので、意見やアドバイスを得たいと思っています. シナリオは次のとおりです。

:products金融商品を格納するモデル/テーブルがあります。もともと別のモデル/テーブルに保存していた各製品has_manyの投資戦略。:strategies各製品には完全に異なる戦略があり、各戦略には異なる属性があるため、各戦略の属性を正規化された一貫した列に操作することは非常に困難 (かつハック) になります (アプリケーションに単純に追加できない製品がある点まで) . さらに、戦略の属性は、その戦略に割り当てられた金額に基づいて変更される場合があります。

この問題を解決するために、:strategiesモデル/テーブルを完全に削除し、単にモデル/テーブルに戦略列を追加することを検討してい:productsます。新しい列には、各製品の戦略の多次元ハッシュが格納されます。このオプションにより、データ ストレージの観点から非常に高い柔軟性が得られます。

私の主な質問は、この方法でデータベースを再構築することによって機能が失われることはありますか? 戦略の属性によって製品を検索する必要がある場合があり、多次元ハッシュ内での検索はせいぜい難しいと読んだことがあります。これは悪い習慣と見なされますか? 私が考慮していない3番目の解決策はありますか?

4

1 に答える 1

0

この設計で複数のテーブルをローリングする利点は、データベースを活用して、制約、関数、およびトリガーでデータを保護できることです。データベースは、100% の信頼で顧客データを保護できる唯一の場所です。これらの実証済みの真の技術は、近年その輝きを失い、それらを理解していない人にとっては扱いにくい、および/または不必要であると見なされています.

リレーショナル データベース内のハッシュ ベースのストアは現在、nosql データベースの人気により急速に変化していますが、従来、この実装で顧客データをデータベースから完全に保護することは困難でした。したがって、アプリケーション層は、この保護の多くが存在する場所です。そうは言っても、これは革新されており、いつか解決されるかもしれません。

ハッシュをテーブルの列として使用することの大きな利点は、問題を把握している間、より迅速に立ち上がることができることです。さらに、ほとんどの変更はその場でアプリケーション層で行われるため、より簡単にピボットできます。

リレーショナル データベース内でハッシュ ベースのストアを使用している場合、全文検索と複雑なクエリも少し難しくなる可能性があります。

一般的な経験則は、データを安全に保管する必要がある場合、または複雑なレポートを作成する必要がある場合は、リレーショナルに移行することです。大規模な金融サービス タイプのアプリを考えてみてください ;) それ以外の場合は、よりソーシャルなデータ表示スタイルのアプリを構築したり、単にモックアップしたりする場合は、シリアル化されたハッシュ列に問題はありません。最も重要なことは、間違った選択をした場合に自信を持ってリファクタリングできるように、テストを作成することを忘れないことです!

私の $0.02

あなたがどちらの決断を下し、それがどのように機能したか知りたいです。

于 2013-12-06T23:33:46.147 に答える