when should I use a static array instead of a new table in my database?

Question

I've implemented an Access Control List using 2 static arrays (for the roles and the resources), but I added a new table in my database for the permissions.

The idea of using a static array for the roles is that we won't create new roles all the time, so the data won't change all the time. I thought the same for the resources, also because I think the resources are something that only the developers should treat, because they're more related to the code than to a data. Do you have any knowledge of why to use a static array instead of a database table? When/why?

Answer 1

The problem with hardcoding values into your code is that compared with a database change, code changes are much more expensive:

• Usually need to create a new package to deploy. That package would need to be regression tested, to verify that no bugs have been introduced. Hint: even if you only change one line of code, regression tests are necessary to verify that nothing went wrong in the build process (e.g. a library isn't correctly packaged causing a module to fail).

• Updating code can mean downtime, which also increases risk because what if the update fails, there always is a risk of this

• In an enterprise environment it is usually a lot quicker to get DB updates approved than code change.

All that costs time/effort/money. Note, in my opinion holding reference data or static data in a database does not mean a hit on performance, because the data can always be cached.

Answer 2

Your static array is an example of 'hard-coding' your data into your program, which is fine if you never ever want to change it.

In my experience, for your use case, this is not ever going to be true, and hard-coding your data into your source will result in you being constantly asked to update those things you assume will never change.

Protip: to a project manager and/or client, nothing is immutable.

Answer 3

I think this just boils down to how you think the database will be used in the future. If you leave the data in arrays, and then later want to create another application that interacts with this database, you will start to have to maintain the roles/resources data in both code bases. But, if you put the roles/resources into the database, the database will be the one authority on them.

I would recommend putting them in the database. You could read the tables into arrays at startup, and you'll have the same performance benefits and the flexibility to have other applications able to get this information.

Also, when/if you get to writing a user management system, it is easier to display the roles/resources of a user by joining the tables than it is to get back the roles/resources IDs and have to look up the pretty names in your arrays.

Answer 4

Using static arrays you get performance, considering that you do not need to access the database all the time, but safety is more important than performance, so I suggest you do the control of permissions in the database.

Study on RBAC.

Answer 5

Things considered static should be coded static. That is if you really consider them static.

But I suggest using class constants instead of static array values.