詳細については触れませんが、これは高度な質問です。
私は常に、制約のない場所に主キーを格納することは決して良い考えではないと考えてきました。たとえば、主キーを EAV スタイルのアーキテクチャに格納します("USER_ID",144)。そのユーザーが削除された場合、EAV マッピングに反映されず、後で問題が発生します。
そのため、フレームワークとして shiro を使用して新しいアプリケーションを作成していsecurity/permissionます。ユーザーは自分自身を編集できる必要がありますが、他のユーザーは編集できません。また、他のユーザーが誰でも編集できる必要があります。簡単です：
user1 = "user:441:edit"
user2 = "user:edit"
さらに、ユーザーのサブセットのみを編集できる人がいる可能性があります。たとえば、次のようになります。
user3 = "user:459:edit","user:460:edit","user:461:edit"
または、ある部署のユーザーを編集できるが、その部署のみを編集できる人
user4 = "department:5898:user:edit"
user3 のリストから誰かが削除された場合、魔法を使わずにそのユーザーの権限を更新する方法はありません (すべての権限を調べて、削除する権限を見つけます)。
現在、キーをリセットする予定はありませんが、古いキーをクリーンアップしないと、古いキーを再利用した後、最近作成されたユーザーを突然編集できるようになる可能性があります。
("user:ciS84nFSHK:edit")すべてのテーブルで一意の生成コードを使用してアクセス許可の削除を管理することで、この一部を軽減できます。ただし、数億のレコードを追加すると、これはすぐに扱いにくくなる可能性があると思います。
Shiro の使い方が間違っていますか？キーがめちゃくちゃになることに集中しすぎているだけですか？これらの問題は解決しましたか？どんな助けでも大歓迎です。