2 つの静的配列 (役割とリソース用) を使用してアクセス制御リストを実装しましたが、権限用にデータベースに新しいテーブルを追加しました。
ロールに静的配列を使用するという考え方は、常に新しいロールを作成するわけではないため、データが常に変更されるわけではありません。リソースについても同じことを考えました。リソースは、データよりもコードに関連しているため、開発者だけが扱うべきものだと思うからです。データベーステーブルの代わりに静的配列を使用する理由について何か知っていますか? いつ/なぜ?
2 つの静的配列 (役割とリソース用) を使用してアクセス制御リストを実装しましたが、権限用にデータベースに新しいテーブルを追加しました。
ロールに静的配列を使用するという考え方は、常に新しいロールを作成するわけではないため、データが常に変更されるわけではありません。リソースについても同じことを考えました。リソースは、データよりもコードに関連しているため、開発者だけが扱うべきものだと思うからです。データベーステーブルの代わりに静的配列を使用する理由について何か知っていますか? いつ/なぜ?
コードに値をハードコーディングする際の問題は、データベースの変更と比較して、コードの変更がはるかにコストがかかることです。
通常、展開する新しいパッケージを作成する必要があります。そのパッケージは、バグが導入されていないことを確認するために、回帰テストを行う必要があります。ヒント: コードを 1 行だけ変更した場合でも、ビルド プロセスで問題が発生していないことを確認するために、リグレッション テストが必要です (たとえば、ライブラリが正しくパッケージ化されていないためにモジュールが失敗するなど)。
コードの更新はダウンタイムを意味する可能性があり、更新が失敗した場合、常にこのリスクが存在するため、リスクも増加します。
エンタープライズ環境では、通常、コードの変更よりも DB の更新の承認を取得する方がはるかに迅速です。
そのすべてに時間/労力/お金がかかります。私の意見では、参照データまたは静的データをデータベースに保持しても、パフォーマンスが低下するわけではありません。データは常にキャッシュできるためです。
静的配列を使用すると、データベースに常にアクセスする必要がないことを考えるとパフォーマンスが得られますが、パフォーマンスよりも安全性が重要であるため、データベースのアクセス許可を制御することをお勧めします。
RBACに関する研究。
静的配列は、データをプログラムに「ハードコーディング」する例です。これは、変更したくない場合でも問題ありません。
私の経験では、あなたのユースケースでは、これは決して真実ではありません。データをソースにハードコーディングすると、決して変わらないと想定しているものを常に更新するよう求められることになります。
ヒント: プロジェクト マネージャーやクライアントにとって、不変のものはありません。
これは、データベースが将来どのように使用されると考えているかにかかっていると思います。データを配列に残し、後でこのデータベースと対話する別のアプリケーションを作成する場合は、両方のコード ベースでロール/リソース データを維持する必要があります。ただし、ロール/リソースをデータベースに配置すると、データベースがそれらの唯一の権限になります。
それらをデータベースに入れることをお勧めします。起動時にテーブルを配列に読み込むことができ、同じパフォーマンス上の利点と、他のアプリケーションがこの情報を取得できる柔軟性が得られます。
また、ユーザー管理システムを作成する場合は、ロール/リソース ID を取得してきれいな名前を検索するよりも、テーブルを結合してユーザーのロール/リソースを表示する方が簡単です。あなたの配列。
静的と見なされるものは、静的にコーディングする必要があります。それは、それらが本当に静的であると考える場合です。
ただし、静的配列値の代わりにクラス定数を使用することをお勧めします。