Use case
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.
Real-life experiences
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.
Features
- General customizing tables
- Possibility to set validity dates and user ids (for testing)
- Usage with our without change requests (customizing or non-customizing)
- Possibility to store structure-like parameters
- Possibility to store multi-value parameters
Learn more on the github readme
Bluesky
