
If there is a need for new customizing parameters in customer projects, we usually create tables, views, view clusters, access routines and so on. What if we used one single table for this? We would have an unique access module and could store as many parameters as we want using an access key.
I used this approach for many years in a mid-range implementation with about 3000 Users. It makes the developing more straightforward when it comes to use settings stored in the database. After 4 years, about 250 different parameter keys accumulated in our generic table. In case we have special requirements such as proper validation of values against domains or check tables, we continue using normal customizing features, but in case of simple setup parameters, the generic table is very helpful.
Learn more on the github readme
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
12 | |
7 | |
6 | |
6 | |
5 | |
5 | |
4 | |
4 | |
4 | |
4 |