0

この質問はそれ自体で答えることができますが、ベストプラクティスの問題でもあります。

ユーザー（会社）がアカウントを作成できるようにするアプリケーションを設計しています。これらのユーザーは、テーブル「Shop_table」に配置されます。shop_employeesこれで、各ショップに動的データがありますが、テーブルは、、、のように各ショップで同じになりshop_infoますshop_data。

ショップごとに特定のテーブルを用意する方が効果的でしょうか、それともショップIDでデータをリンクするだけでよいでしょうか。

例えば：

shop: Dunkins with id:1 
shop: Starbucks with id:2

ダンキンには独自の、、dunkins_shop_employeesテーブルdunkins_shop_infoがdunkins_shop_dataあり、スターバックスには独自starbucks_shop_employeesのstarbucks_shop_info、、がありますstarbucks_shop_data

または、1つのテーブル shope_employees、、、およびID1または2によるリンクなどがあります。shop_infoshop_data

4

2 に答える 2

0

テーブルは1つだけにする必要があります（それぞれにshop_infoなど）。

同様のテーブルを作成することは、メンテナンスの悪夢です。同様の外部キー、同様の制約、同様のインデックスなどを作成する必要があります。

プライバシーが懸念される場合は、アプリケーションでこれを制御する必要があります。アプリケーションは、誰がログイン/クエリを実行しているかに基づいて、常に「WHERE」句を追加する必要があります。

どうしても必要な場合は、whowhere句をshop_idとしてビューを作成できます。ビューのみでさまざまな人に権利を与えることができます。これは、SQLレベルのクエリ機能を必要とする大口顧客がいる場合にのみ意味があります。

于 2012-05-17T23:25:53.077 に答える
0

会社を識別するためのフィールドを持つエンティティごとに間違いなく1つのテーブル。

すべての会社が同じ情報を持っている場合、それぞれにテーブルを作成する必要はありません。あなたが行った場合、クエリは悪夢になります。

企業全体の集合体データを取得するために、本当に大量のUNIONクエリが必要ですか？また、別の会社（したがって複数のテーブル）が追加されたらすぐに、DB内のすべてのクエリを変更する必要があります。

テーブルを個別に定義し、保存するエンティティをモデル化し、それらが誰に属しているかを考えないでください。

于 2012-05-17T23:07:16.090 に答える