0

ユーザーがアプリに認証され、todo リスト項目を保存できるシンプルな todo リスト webapp の設計の練習に忙しくしています。ユーザーは、自分が追加した todo リスト アイテムのみを表示/編集することもできます。

これは、ほとんどの Web アプリケーション (または一般的なアプリケーション) の一般的な機能 (認証されたユーザーは自分のデータのみを表示する) のようです。

私にとって重要なことは、これを達成するためのさまざまなオプションについての知識を持つことです。私が達成したいのは、多くのユーザーのデータを効果的に処理できるソリューションです。現時点では、リレーショナル データベースを使用してこれを行っていますが、noSQL の回答も役に立ちます。

次のアイデアが浮かびました。

  • この「機能」が必要になるたびに、user_id 列を追加します。
  • データを関連付ける関連付けテーブル (上記の例では user_todo_list_item テーブル) を追加します。
  • 「機能」ごとにユーザーごとにテーブルを作成するように設計します。つまり、todolist_userABC テーブルが作成されます。それはオプションですが、1,000 ユーザーは 1,000 テーブルを意味するので、あまり好きではありません。
  • 特定の「機能」に行レベルのセキュリティを追加します。これがどのように機能するかはよくわかりませんが、有効なオプションのようです。これがデータベース ベンダー固有のものかどうかもわかりません。

    私が選んだのは、todolist_item テーブルの user_id 列です。仕事はできますが、テーブル内のデータが十分に大きくなると、データを読み取るときに user_id 列が問題になる可能性があると感じています。私が推測するインデックスを追加することもできますが、インデックスの有効性についてはわかりません。

    私が気に入らないのは、このタイプの機能が必要なすべてのテーブルに user_id が必要であることです。これは私には正しくないようです。また、データベース層を実装するときに、すべての機能のクエリにこれを追加する必要があるようです (AOP を使用しない限り)。

    ( Trello は MongoDB にデータをどのように保存しますか? (ボードごとのコレクション?) )を調べましたが、user_id 列などに関する手法については触れていません。私はまた、いくつかのセキュリティフレームワーク（具体的にはSpring Security）でこれについて読んでみましたが、行レベルではなくテーブルレベルでの特権/許可にのみ入るようです?

    問題は、私の選択が適切であったかどうか、そしてこれを行うためのより良い手法があるかどうかです。

    • 4

    1 に答える 1

    0

    あなたの選択は自然なことです。

    ユーザーごとのテーブルは初心者ではありません（ユーザーのアクションに応じてデータベース構造を変更するものは通常疑わしいものです）。

    行レベルのセキュリティは、実際にはWebアプリケーションのオプションではありません。各ユーザーセッションには、データベースへの個別の永続的な接続が必要ですが、これはほとんど実用的ではありません。そして、はい、それはベンダー固有です。

    テーブルにインデックスを付ける方法は、使用パターンと実行するクエリの種類に完全に依存します。'ユーザーのすべてのTODOを表示する'サポートしたいクエリですか（そうなるようです）？次に、ユーザーIDのインデックスが明らかに必要です。

    user_id列を持つことがあなたにとって間違っているように見えるのはなぜですか？ユーザーによるアクセスを制限する場合は、レコードが属するユーザーを識別できる必要があります。実際には、すべてのテーブルがそれを必要とするという意味ではありません。たとえば、あるレコードが別のレコードを構成する場合（たとえば、TODOに「ステップ」があり、各ステップは単一のTODOに属します）、オブジェクトグラフのルートのみがユーザーIDを必要とします。

    于 2013-01-08T20:00:40.167 に答える