The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Global Variables in Database a Good Idea?

A company that I've recently worked for had an interesting element in their core software products. I've never seen it before, so I thought I'd ask the minds in this group what they think. I might understand if this was a data intensive application, but it's just a fairly typical desktop application.

The applications had global variables that were stored in a customized database. The fact that this was a custom DBMS removes the performance hit one would take constantly calling something like Oracle, SQL Server, etc. At the same time, these apps have performance requirements similar to normal dektop apps, so what little performance hit is caused by this is irrelevant.

It adds the ability to do event driven stuff based on variable changes. There's something like a "on variable change value notify module x" event built into the database, based on flags associated with each variable. The entire application is queued event driven.

The downside that I can see is that it increases the use of global variables. There is no security provided against code modifying the variable in the database (i.e. the usual argument against using a global variable).

Any thoughts?
A. Gorilla
Wednesday, July 13, 2005
 
 
There is nothing inherently evil in global variables. The use profile of most values is such that they do not fit (e.g., they need per-context value, and the context is per object, per thread, etc.). But some values are inherently global, and the anti-globalalization mob will not admit to that, but rather work 20 times as hard.

If the database is good enough for this (e.g., TimesTen, kdb+, probably a few others), then it's probably a good solution.

Don't believe the anti-globalization mob, nor the oo-mob. A good relational database is all you need 95% of the time, and will serve you better. Even the lousy excuses sold as relational databases these days (they aren't, strictly speaking, relational, and neither is SQL).
Ori Berger
Thursday, July 14, 2005
 
 
If they are doing this because the variables are "global" to multiple applications then I would say that this is as good a way to implement it as any other way. Sharing data between applications using a database is probably the easiest way to do it.

If the variables are "global" to a single application and they are doing this because they needed to monitor changes to variables then I would say that this is poor design. There are plenty of other ways to do that (depending on the language).

We probably can't comment further without getting more information about the actual circumstances: language, number of variables, number of modules/applications, etc.
matt
Thursday, July 14, 2005
 
 
Also, does the application potentially do this for error recovery? If the global variables are stored in the database then you could potentially pick back up where you left off after a power hit.

There may be more than one aspect to this design. It could be done to facilitate eventing, error recovery, and inter-application communications/data sharing.
matt
Thursday, July 14, 2005
 
 
I believe that everything *except* the database connection string should be stored in the database.  It makes programatic access easier and allows for all kinds of nifty extensions.
KC Send private email
Thursday, July 14, 2005
 
 
KC... I am assuming that you only work on web apps?
matt
Thursday, July 14, 2005
 
 
Gorilla,

You said, "It adds the ability to do event driven stuff based on variable changes. There's something like a "on variable change value notify module x" event built into the database, based on flags associated with each variable. The entire application is queued event driven."

You can do this with triggers in the big databases too.  Oracle has triggers that can cause stored procedures to run when a database row is updated. The stored procedure can do whatever you need, including runing external programs.  I'm pretty sure you can do the same in SQL Server.
XYZZY
Friday, July 15, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz