0

私はいくつかの Q&A を見直しましたが、私の主題に特有の何かが私がフェンスから抜け出すのに役立つと思いました.

いくつかの異なる式と何百もの異なる材料タイプに基づいて価格を計算するアプリがあります。

ユーザー A は、式 A と材料 A、B、C を使用できます

ユーザー B は式 A と材料 A、B、C を使用し、+ 他の誰も使用していない材料を追加したい 材料 unique_A

ユーザー A がアプリを使用しているとき、彼はユーザー B の独自の素材を見たくありません。

ユーザーごとに独自のマテリアル テーブルを使用することを考えていました。これにより、マテリアルのリストを取得するのが「より速く???より効率的???」になります。ユーザーが 1 つのグローバル テーブルから必要な材料。

どちらの方法が良いですか？ユーザーごとに 1 つのテーブルですか、それとも一意のテーブルですか?

4

3 に答える 3

2

あなたはすべての材料のテーブルを持つことができます.

  materials = (id, name, other attributes...)

およびユーザーのテーブル:

  myusers = (id, name, etc....)

次に、これら 2 つの間の多対多の関係を基本的に表すテーブルを作成できます。

  user_materials = (user_id, material_id)

次に、これらのテーブルを結合することにより、ユーザーが使用する特定の材料を選択できます。アプリケーションに関しては、この配置は、ユーザーごとにテーブルを作成しようとするよりも優れています。クエリが難しくなります。このようにして、次の質問に対する答えも得られます: どのユーザーがマテリアル A を使用していますか?

于 2013-03-07T15:58:29.267 に答える
0

非常に少数のユーザーがいて、それぞれが独自の安定した変更されないアイテムを持っていない限り、これを行う意味はありません。さらに、ユーザーとマテリアルのドメインについて話している場合、パフォーマンスの問題に遭遇することはほとんどありません。どちらも何百万もあるわけではありませんよね？

于 2013-03-07T16:00:01.473 に答える
0

データベースの「ベスト プラクティス」の 1 つは、情報の重複を減らすことです。実際には、そこにある理論のほぼすべての分野にそのバリエーションが存在します。

ただし、ユーザーごとに一意のテーブルを使用するアプローチはお勧めできません。データが重複するだけでなく、そのようなデータベースを維持することは、ユーザーの数が増えるにつれて膨大な作業になります。

私は、材料のグローバルテーブル、ユーザーのテーブル、およびユーザーが必要とする材料のテーブルを用意したいと考えています。

データベースとデータベースにアクセスする必要があるコードの両方の複雑さと情報の重複を減らすため、「1 テーブル アプローチ」の方が優れていると見なすことができます。

于 2013-03-07T16:00:53.827 に答える