アプリケーションのデータベース（MySQL）に結合テーブルがあり、これは大幅に大きくなります。
私はユーザーと製品の2つのモデルを持っています、ユーザーは表示する多くの製品を持っています、そして製品はそれをどのように表示するか多くのユーザーに属しています。
開始時に、すべてのユーザーが表示するすべての製品を持ち、ユーザーは表示できる製品を編集できます。
テーブルサイズが（n * m）nはユーザー数（大きい）、mは製品数（これも大きい）であり、テーブルの読み取り操作が遅くなるという問題。
例：3人のユーザーのID： "1,2,3"
と3つの製品のID： "1,2,3"
したがって、users_productsテーブルは次のようになります。
user_id、product_id
1、1 1、2 1、3 2、1
2、2 2、3 3、1 3、2 3、3
別のデータベースシステムを使用するためにこの部分を再設計することから始めて、私はすべての解決策にオープンです。
前もって感謝します。
おそらく真実ではない何かを仮定していると思います。SQL サーバーは、多くの行がある場合でも、この種のクエリをすばやく処理します。適切なインデックスがあれば、1,000 万件のレコードを含むテーブルを非常に高速にクエリできます。
あらゆる種類の時期尚早な最適化を行う前に、いくつかのテストを行うことをお勧めします。
Pieter-JanがNeo4Jで指摘したように、代替ソリューションがあります。私はCouchbaseとNeo4Jの両方の大ファンです。これは単純なリストであり、リレーショナルテーブルはこれらの操作にはあまり適していません。
Couchbaseでは、これを複数の方法で行うことができます。1つは、単純なclient.appendを使用して製品のリストを保持し、次に単一のclient.getを使用してリストを取得することです。これには、追加前の重複排除と、追加後の重複排除の2つの可能性があります。リストを取得するのに非常に高速で、あらゆる形式のクエリを消去します。
別の方法は、JSONを使用し、ユーザーがアクセスして表示できる各製品の配列などを用意することです。最初の例の上記の単純な文字列と同じですが、必要に応じてJSON。
どちらの場合も、どのタイプのクエリよりもパフォーマンスが優れています。
Neo4Jを調べましたか？これは十分に文書化されたグラフ データベースであり、私の意見では、この特定のユース ケースに最適です。これをモデリングする方法はとても簡単です。
すべてのユーザーとすべての製品は、ノードによって表されます。それらの間に関係「IS_ABLE_TO_SEE」を作成するか、作成しないかのどちらかです。
その後、さまざまな機能を使用して、このデータを再度取得できます。私のお気に入りはトラバーサルの使用です。ノードから開始し、リレーションをウォークスルーします (どのノードをどの方向にウォークするかを選択できます)。ただし、これは、互いに数レベルの深さが離れているデータを取得する場合により便利です。
この特定の使用例では、リレーション「IS_ABLE_TO_SEE」を介してユーザー ノードに接続されているすべての製品ノードを返す単純なクエリを実行できます。
Neo4J は、グラフ データベースの経験がない人にとって非常にアクセスしやすく、前述したように、ここで紹介するユース ケースに合わせて作成されています。