2

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.

  • Is this an abstract question or are you actually faced with this issue? If you're actually faced with this issue, it smells like an XY Problem. – Sean McSomething Jul 19 '13 at 1:05
  • 1
    This looks like an XY Problem except that the solution was imposed to me. I perfectly know how to do it in a better, safer way but methods I've described here have been chosen for me and I have implement them. I asked this question to know if such methods are used sometimes and how to reduce their impact of the application stability and security. This may look stupid to implement something I don't really know and that seems awful to me, but I work in a very close-minded society in which technical decisions are taken by non-developing staff ... – ibi0tux Jul 19 '13 at 6:27
1

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.)

  • In my opinion the is a major problem of the architecture i have to work with is that it is based on names only. I could have opened another topic for that but even graphical items are linked to database fields by the name that must be the same to get an automatized matching. I think names are just an abstract that can not define the concept that uses this name. As counter-example, I've been told that frameworks/softwares like Django, SPIP or SAP are mostly working on this way : storing their own structure in the user database, but I'm remain very skeptikal about the scalability of such models. – ibi0tux Jul 17 '13 at 15:15
1

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/

  • "First I want to make sure. You're storing names and classes, but not raw code, right?". Both. Some tables only contain names of classes or name of other tables column, but there are also tables that contains raw code that is intended to be executed directly. – ibi0tux Jul 17 '13 at 15:56
  • 1
    @ibi0tux There are valid reasons to store raw code in databases. But the majority of the time someone does it because "it can support anything" and it is a long-term development headache. If it is not in your power to change, well such is life. But no, I would not recommend that design. – btilly Jul 18 '13 at 5:20
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.