I would like to know if this is a good practice to store variables and classes names in database to use let users accessing them.
For instance users may create entries in database's table in which they can insert a program's function name that would executed when the program will read it.
I find it is a dangerous practice since users may execute or access any data of the program, but I've been told it's a quite common practice in languages with introspection like Python.
Moreover, i was also suggested to have field in a table that would store another table field's name, to create somehow a dynamic foreign key.
I personally find both practices very bad since in first case there is no more separation between user data and program data, and for the second case there is no separation between structure and data in the database.
Can you please confirm me these practices are discouraged or tell me I'm wrong and suggest me a way to approach them in a safer way.
Thank you.
Best Answer
First I want to make sure. You're storing names and classes, but not raw code, right?
The problem with code in the database is that databases do not have a well-developed toolset for commit/rollback/release/branching/etc like we have with files. Furthermore keeping code+database in sync is an eternal source of potential problems. 90% of the time there is no issue, but that makes for a 10% source of completely unnecessary problems.
Having class names and function names in the database is very flexible. The problem is that then nothing can be ever assumed to not be referenced from that database. Which means that any potential refactorings are forever verboten.
Instead what I would recommend is that you store a very simple stupid "translation layer" (which mostly does no translation) that does nothing but sit in your code and map from class/function names in your code to corresponding ones in the database. This adds no immediate functionality except to serve as documentation about what kinds of information are allowed to be stored in the database and (just as important) what is not. This serves as internal documentation of your public API which will allow refactoring/cleanup to happen later.
In short, it allows you to pass the grep test: http://jamie-wong.com/2013/07/12/grep-test/