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.
2
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/
2
This has nothing to do with data bases in particular. A data base is merely a device for preserving assets of your program across different invocations cheaply and reliably. The question is: is it sensible to treat the names rather than the contents of object attributes, classes, etc. as assets in your program or not?
If it is, then saving and restoring them from a data base is the obvious thing to do when you need persistence. If it isn’t, then there may be obvious problems with the practice, but those aren’t related to persistence, they would be just as grave when applied to the architecture of your application in the first place.
(I’m exaggerating slightly here. Saving data to persistent storage inevitably introduces the problem of legacy data that must be handled by new versions of the code, i.e. by code that isn’t the same code which created them. Data base schemas are notoriously long-lived and often not under your complete control, because they must be shared with other applications in your business. Therefore, storing data persistently tends to amplify any architectural problems your code has. Nevertheless, the main point is that reflection may or may not be appropriate, but not because it causes weird table or schema elements.)
1
Microsoft stores meta-data about SQL Server objects in a database. However, this meta-data is not intended for the use of anyone except a database admin who is supposed to be expert enough not to mess with it directly. So while there can be a valid case for storing such data in a database for system use, the case for allowing a typical user access to it and the ability to change it without understanding what that means is far more risky. It is the worst of all worlds if your users are not typical expert level sys admins or DBAs or developers themselves. Further, code should be in source control and having it there and in the database means it will get out of synch. And the whole idea of some type of dynamic FK strikes horror into my mind no matter how it is implemented as that is a recipe for data integrity problems.