2

単純なユーザー/ロール情報を格納するためのデータベーステーブルを設計する場合、ロール情報をユーザーテーブルに直接格納することがなぜ悪い考えであるかを誰かに教えてもらえますか（たとえば、[コンマ-ロールで区切る]列）。

考え：

  1. データベースは、UIのドメインであるロールについて知る必要はありません。
  2. 特定のユーザーの役割へのアクセスが速いほど良い
  3. 確かに、将来、特定の役割のすべてのユーザーにアクセスしたい場合は、クエリが

少し遅くなりますが、その時点で誰が気にしますか？

これは意味がありますか？私はロッカーから離れていますか？RolesテーブルとUserRoleテーブルを作成するのはやり過ぎで、不要なSQLとコードのオーバーヘッドを追加しませんか？

アップデート：

私のポイントをさらに説明するために...コードで、ユーザー「Steve」がロール「Administrator」にあるかどうかを知りたいです。

オプション1：UserRoleテーブルで、ユーザー「Steve」のロールのリストを照会します。そのリストをループして、RoleNameが「Administrator」と一致するかどうかを確認します。

オプション2：ユーザーの役割プロパティでcsvを分割し、結果のリストに「管理者」が含まれているかどうかを確認します

更新II：

私の提案は、特にDB設計に関して、あらゆる種類の「ベストプラクティス」タイプの考え方に違反していることに同意します。ただし、この種のシナリオで「ベストプラクティス」がどのように意味をなすのかはわかりません。私は時々ベストプラクティスのボートを揺さぶるのが好きです...私は賢く見える方法でコーディングするのが好きです。つまり、賢くないときを知るためにもっと理解する必要があることを意味します:)

4

5 に答える 5

2

第3正規形に違反しているため。すべてのエンティティを異なるオブジェクトとして分離する必要があります。つまり、個別のテーブルとリレーションシップテーブルが必要です。

データの違反

これらすべてを1つのテーブルに保持すると、ユーザーに関する無関係な情報がユーザーのテーブルに配置されすぎてしまいます。ユーザーのテーブルには、名前、ユーザーアカウントなど、そのユーザーにのみ関係するフィールドが含まれている必要があります。ただし、この場合、ロール情報を入力することにしました。ユーザーとは必ずしも関係のない属性を追加しているため、これは意味がありません。

その結果、ユーザーに関係のないフィールドを追加し始め、無関係な情報が大量に発生することになります。これに対する解決策は、次のようなユーザーテーブルを用意することです。

User table
UserID
User
...

Role table
RoleID
Role
....

User Role Table (the relationship)
UserRoles
UserID
RoleID
...

データの更新/挿入

ユーザーのテーブル内に役割情報を格納する場合に対処しなければならない次の問題は、有効な更新、挿入を実行する方法です。これはそれをさらに難しくします。レコードを編集するときは、CSVから正しい値を編集していることを確認する必要があります。

適切な役割を見つける

ここに最も難しい問題があります。それは、ユーザーに与えられた役割を見つける方法です。C＃またはSQL Serverでこの優れた解析手法を思い付くかもしれませんが、それはうまく機能します。しかし、それはひどく遅くなり、読みにくくなります。SubString()ユーザーの役割を解析するためだけにLeft()、、、、およびその他の多数の関数の Right()処理を開始します。Len()

ソリューション

今のところ、すべてを1つのテーブルにまとめる方が簡単だと思うかもしれません。おそらく、事前の時間が大幅に短縮されます。ただし、将来を念頭に置いてアプリケーションを開発する必要があります。3nfのルールに従い、優れたリレーショナル構造を作成すると、UIははるかに単純になります。UI管理画面が見栄えがするだけでなく、特定のUserIDの役割を取得することは、解析や検索とは対照的に、非常に簡単です...

于 2011-06-06T19:36:34.970 に答える
1

素晴らしい計画ではないと思います。誰かの役割を手動で更新していて、役割の名前を少し間違って入力したとしますか？別のテーブルがある場合は、データベースの制約によって警告が表示されます。役割の名前を変更することにしたとしましょう。別のテーブルがある場合は、1か所で変更するだけで済みます。

データベースの正規化は、正当な理由で行われます。それはただのつまらないだけではありません。コードベース内のキーコードを複数の場所で繰り返すことはありません。データベースの非正規化は同等です。

追加するために編集：あなたは、アプリケーションがデータベースによって返された値に基づいて最終的に決定を下すということを強調します。たとえば、ユーザーが「管理者」と呼ばれる役割を持っている場合に特定のオプションを付与します。これは真実であり、たとえば役割名の一貫性が損なわれる可能性がある別の別の場所です。データベースを非正規化しても、これが起こりにくくなるとは思いません。

これを支援するための1つの良いアプローチ（および一般的な承認を実装するための良い方法）は、役割が特定の一般的な能力に変換されるコード内の単一の場所を持つことです（たとえば、管理者はすべてのエンティティを読み書きでき、ゲストは特定のエンティティを読み取ることができます）何も書けないなど）。次に、アクセスを確立する必要がある多くの場所で、役割に対してチェックするのではなく、能力に対してチェックします。

つまり、ビューで、アイテムの説明に「編集」ボタンを表示するかどうかを決定する場合は、を実行してチェックするのではなく、を実行してif role=='ADMIN' or role=='EDITOR'チェックしますif user.can_edit(item)。管理者と編集者がアイテムを編集できるようになることを確立した他の場所。たとえば、Rails認証システムCanCanが使用するアプローチを参照してください。

このアプローチを使用すると、役割の名前を参照する場所は1つだけになります（たとえば、CanCanでは、役割に基づいて誰が何を実行できるかについてのすべてのルールを定義する「能力」というクラスがあります。それ以外の場所では、ユーザーが何ができるか、何が見えるかを判断するために必要な能力を参照します。

于 2011-06-06T19:40:11.467 に答える
0
  1. コード側でCSVを解析するには、追加のロジックが必要です。
  2. ほとんどのORMはCSVをサポートしていません。
  3. 長いロール名（例：UserWhoHaveAccessToXObjButNotYObjAndAtTheSameTimeCanDoZ）がある場合は、すべてのユーザーに対してそれを繰り返すスペースを無駄にしています。

また、最初の仮定がすべての状況に当てはまるわけではありません。MYデータベースがロールについて知る必要がある場合はどうなりますか？

于 2011-06-06T19:41:51.053 に答える
0

データベース管理システムでデータを管理するか、アプリケーションでデータを管理するかによって異なります。ほとんどの場合、DBMSはそのために構築されているため、より優れた仕事をします。

于 2011-06-06T20:32:35.060 に答える
-1

あなたが言った

では、アプリケーションでのみロールを定義して、アプリケーションでのみロールを定義してはどうでしょうか。

「どのアプリケーションがこのデータベースにアクセスしても、どの言語でプログラムされていても、すべてのプログラマーとすべてのデータベース管理者が手動でデータの整合性を完全に維持できると100％確信しています。プログラマーがどれほど経験豊富または未経験であり、データベースがどれほど複雑になっても、今からその寿命が尽きるまで。」

あなたがプログラミングプロジェクトを管理するキャリアのポイントに到達した場合、あなたの仕事の一部は、それらを実行するのに最も適した人にコーディングの責任を割り当てることです。アーキテクチャレベルでは、誰かがデータの整合性などのプログラムの責任を、それらを実行するのに最適なモジュールまたはサブシステムに割り当てます。データの整合性は、その責任をデータベース管理システムに割り当てることによってのみ保証されます。コードであろうと人間であろうと、システムの他の部分にそれを割り当てることは、単なる希望の表現であり、希望はうまくスケーリングしません。

于 2011-06-06T22:54:05.787 に答える