The article makes a good point, but I would argue its not the whole truth.
A proper (relational) database does more than just storing values. It also stores relations between different values. And SQL is an extremely powerful way of working with those relations. I see the point that the author makes about projects with a database/state being worse, but in some projects I’ve worked on, I’ve been able to offload a great deal of work into the database schema.
And also, a database doesn’t just store a few measly little variables. Often, you’ll be storing gigabytes or more in there. That’s completely infeasible to pass from function to function, or sometimes even hold in RAM at once. The point of a database is to store and manage data, in amounts that you don’t want to have to deal with yourself.
it’s common programming advice that global variables are bad
They’re not. This is what we tell beginners because one needs to be careful when maintaining a global state and beginners often do it horribly.
But having a global state is sometimes the right solution.
Pro tip: if you ever find yourself saying “x programming practice is always wrong” you’re probably wrong.
Yes always is probably wrong, but not having global state allows you to argue just by function signature and allows easier unit testing and multithreading and probably more.
The thing is - you almost always have “a global state” of sorts it’s just all about how you access it. And the guidance is to do so though well defined interfaces as you say.
But sometimes a global variable really is a good solution. A logger or config object can often be handled pretty well as “global” vars. You don’t generally want to pass loggers to every single function call.
A database is a store for globals only if we don’t care too much about introducing complexity.
Globals often need to have the following properties:
- Need to persist for the duration of the program.
- Everybody needs the latest value out of the global variable.
Now both of these things don’t need to be explicitly a “global variable” in the programming sense. Logically speaking we just need code that implements the behaviour of the global variable well enough to satisfy our requirements.
most DBs are most often an overkill for our requirements of a global variable.
sqlite is a fantastic fit for this use-case if one wants some level of ACID properties.
One can go with a redis cache or some other kind of disk caching KV store.
Or simply just go with a global variable and measure how it does before doing all this crap.
That’s a weird take.
Isn’t a database only as global as you make it? The connection is surely a real object that needs to be passed around and referenced just like any other.
I don’t really touch JavaScript or web dev so I might be misunderstanding the domain usage.
I think his point is more that you might have multiple components that need database access in your app, so those component have a connection (or reuse a central access) and for simplicity reasons, you made 1 database for the whole app, rather than one per component. Once that happens there’s a new path that could be used to pass information between the components in a way that isn’t the function interface. Much like a global variable can be used that way. And there’s a risk you start to use the database like a global variable store.
I don’t use databases much, so I don’t have a strong opinion, but it’s an interesting thought.
