一般に、NoSQL ソリューションは開始するのが簡単ですが、将来最適化するのが難しくなる可能性があります。古いレコードの構造を最新の状態に保つために特別な努力をしない限り、アプリケーションが進化するにつれて、異なる構造を持つ異なる世代のレコードが作成される可能性があります。
一般に、SQL ソリューションはより厳格であり、事前により多くの計画を立てる必要がありますが、一方では非常に成熟した技術であり、データの構造を強化し、一貫性を維持するように特別に設計されています。
あなたの場合、SQL を選択します。レコード ストアにはほとんどが長期保存されるデータが含まれるため、安定した構造を課すことでメリットが得られます。私の意見では、NoSQL は、古いデータの整合性と構造 (チャット、ゲームのスコアボードなど) にそれほど関心がない、非常に短期間のデータを処理するアプリケーションにより適しています。
どちらの方法でも決定を後押しする可能性のある要因は多数あります。
最初に自分のデータについて自問する質問のいくつかは次のとおりです。
データはどのくらい大きくなる可能性がありますか? データベースは、在庫があるものだけを保持する必要がありますか?それとも、市場で入手可能なすべてのタイトルを保持する必要がありますか? あなたのデータベースには、あなたが言及した2つよりも多くのテーブルがあると思います。
考えられる答え: 最初に NoSQL 構造を選択することで、後で優れたスケーラビリティの範囲が提供されたことに感謝することができます。
私のデータはどのくらい複雑ですか? 多値列の可能性はありますか?
たとえば、アーティスト テーブルがある場合、このテーブルに、リリース テーブルへの相互参照を容易にするために、そのアーティストの複数値のリリース ID を格納するリリース カラムを含めることができます。この場合、多値データベースなどの NoSQL タイプのデータベースは、パフォーマンスに悪影響を与える結合を回避できるため、興味深い場合があります。データが大きくなると、SQL ルートを使用するよりもデータ取得速度が向上する可能性があります。
選択する SQL データベースによっては、コスト面も考慮する必要があります。
NoSQL ルートを使用する場合は、このルートが提供する柔軟性を最初から適切な初期データ設計でバックアップする必要があります。これにより、後で柔軟性が敵にならないようにすることができます。
それが役立つことを願っています。