3

私たちは、それぞれが異なるプロパティを持つ約5つの異なるユーザーロールを特徴とするWebサイトに取り組んでいます。データベーススキーマの現在のバージョンには、すべてのユーザーとそのすべてのプロパティを保持する単一のユーザーテーブルがあります。

問題は、必要なプロパティがユーザーロールごとに異なることです。すべてのユーザーは、名前、電子メールアドレス、パスワードなど、同じ基本プロパティを持っています。しかし、それに加えて、プロパティは役割ごとに異なります。ソーシャルメディアリンクを持っているものもあれば、請求書アドレスを持っているものもあります。合計で最大60の列（プロパティ）があり、そのうちの一部だけが各ユーザーロールによって使用されます。

合計で、テーブルには約250,000人のユーザーがいる可能性があり、そのうちの最大の部分（約220,000）は単一のユーザーロールになります（60列のうち約20列を使用します）。他の30,000人のユーザーは、他の4つのルールに分割され、他の40列のサブセットを使用します。

開発の観点から、DBの両方から、これに最適なデータベース構造は何ですか？私の考えは、基本ユーザーテーブルを作成し、それをusers _ moderatorsのようなテーブルで拡張することですが、これにより、多くのJOINクエリが発生する可能性があります。これを防ぐ方法はVIEWを使用することですが、私はVIEWがパフォーマンスに悪影響を与える可能性があるいくつかの（時代遅れの？）記事を読みました：http ：//www.mysqlperformanceblog.com/2007/08/12/mysql-view -as-performance-troublemaker/。

「完璧な」構造も存在しますか？何か提案がありますか、それともこれは本当に問題ではないので、すべてのユーザーを1つの大きなテーブルに配置する必要がありますか？

4

4 に答える 4

2

これには 2 つの異なる方法があります。1つは「単一テーブル継承」と呼ばれます。これは基本的にコメントを求めるデザインです。継ぎ目が無いのでかなり速いです。ただし、ファット行はシンナー行よりもメモリに取り込むのに少し時間がかかるため、NULL はスループットにわずかな影響を与える可能性があります。

別の設計は、「クラス テーブルの継承」と呼ばれます。この設計では、スーパー クラス用に 1 つのテーブルと、各サブクラス用に 1 つのテーブルがあります。非キー属性は、関連するテーブルに入ります。多くの場合、この設計では「共有主キー」と呼ばれる設計を使用できます。共有主キーでは、サブクラス テーブルのキー ID は、スーパークラス テーブルの対応する行からの ID のコピーです。

挿入時には少し手間がかかりますが、データを結合するときに元が取れます。

SO (独自のタグがあります) または Web でこれら 3 つすべてを検索する必要があります。デザインの詳細と、各デザインがケースにどの程度適合しているかを示します。

于 2012-12-01T21:32:02.307 に答える
1

そのような場合の「完璧な」構造は、私の意見では、当事者-役割-関係モデルです。データ モデルに関する Len Silverston の書籍を検索します。最初はかなり複雑に見えますが、非常に柔軟です...

最大の問題は、完全なソリューションを採用することの実用性です。あなた以外の誰もそれに答えることができません。リファクタリングは決して簡単で迅速な作業ではありません。たとえば、プロジェクトの存続期間が 1 年間の場合、「技術的負債」の支払いに 9 か月を費やすのは、時間や労力などを無駄にしているように聞こえます。

結合のパフォーマンスに関しては、通常、適切なインデックスを使用することで潜在的な問題が解決されます。そうでない場合は、いつでもマテリアライズド ビューを実装できます。mysql にはすぐに使用できるオプションはありませんが、自分で設計してさまざまな方法で更新できます (たとえば、トリガーを使用するか、更新手順を定期的/オンデマンドで起動するなど)。

于 2012-12-01T14:28:34.703 に答える
1

table user table roles table permissions table userRole table userPermission table RolesPermissions

各ロールには、ロール権限テーブルの権限があります。各ユーザーは、ロールなしで権限を持つことができます (拡張子...)

したがって、PHP では、ユーザー ロールと拡張アクセス許可のユーザー アクセス許可の配列をマージするだけで済みます...そして、「acl」クラスで、ユーザーが Web ページまたはシステム プロセスを表示または処理するアクセス許可を持っているかどうかを確認します...

于 2012-12-02T18:23:01.103 に答える
0

速度はそこまで気にしなくてもいいと思います。1回限りの物になりますので。つまり、セッション内のユーザー ログイン ストア acl で、次回はそこから取得します。

JOIN はそれほど悪くありません。InnoDB エンジンを使用してインデックスと外部キーを適切な場所に配置すると、非常に高速になります。

ユーザーと role_id に 1 つのテーブルを使用します。役割を持つ 2 番目のテーブル。リソース用の 3 番目のテーブルと、すべてをリンクするテーブル + 有効フラグ。

于 2012-12-01T14:23:03.867 に答える