SQLバックグラウンドから来ています。ユーザーの特定の属性に基づいてデータへのアクセスを制限する場合は、ビューを作成し、ビューの基準に基づいてユーザーに表示されるデータを制限するフィルタとしてそのビューを使用できます。このアプローチは関係に依存しており、今まで私のために働いていました。 NoSqlと戦略とコンセプトの変化を見ると、NoSqlの性質をどのように実装するのか混乱しています。このような問題に対するNoSQLのアプローチは何ですか？ユーザーがユーザーの種類に基づいて特定の行にアクセスしていない場合たとえば、管理者は特定のグループのすべてのレコードを見ることができ、一般的なユーザーはグループ内で公開されているレコードと特定のグループレベルのアイテム、グループ写真、グループメッセージなどしか見ることができないとします。私は本当にこの問題へのSQLのアプローチの観点から考えずに私の頭を包み込むことを試みていますが、私はNoSqlに慣れていないので難題です。データの行に許可を与えるためのNoSQL戦略
NoSQLデータベースは、多くの点でリレーショナルデータベースとは概念的に異なります。承認とセキュリティは一般的には主要な焦点ではありません。しかし、そのほとんどはその領域で進化しており、きめ細かい認可を受けています。基本的には、特定のデータベースに依存します。
たとえば、Cassandraはプラン（https://issues.apache.org/jira/browse/CASSANDRA-12859）で列レベルのアクセス許可を持ち、HBaseにはセルレベルのアクセス許可（https://www.cloudera.com/documentation/enterprise/5-8-x/topics/cdh_sg_hbase_authorization.html）があります。一方、MongoDBは一般的にはスキーマレスであり、異なる（より複雑な）ドキュメント指向のデータモデルを持ち、低レベルのアクセス制御を実装することを難しくしています。さらに、MongoDBにはビューがあります。
使用しているDBMSに期待されるレベルの権限が組み込まれていない場合は、dbとやりとりするアプリケーション内で実装する必要があります（複数のアプリケーションがある場合、いくつかの使用規則を確立する必要があります）。非正規化モデルを使用することは一般的なことです。異なるロール/グループは、そのロール/グループだけが見ることができるデータを含むさまざまなテーブル/コレクションとやり取りできます（基本的にはRDBMSビューのシミュレーションです）。この非正規化アプローチは通常、より多くの領域を必要とし、コピーを同期して保持する必要があります。 DBMSが投影をサポートしている場合、異なるロール/グループに対して列/フィールドのサブセットを表示することができます（この方法では、少なくとも一部はdb側で処理されます）。
これは遅くても役立ちます。