Why isn't a database considered a form of global state?

I have a general gut feeling about the difference but I'm unable to pinpoint exactly what makes a database different from global state.

With a naive definition of "global state", a database is generally at least application-global. You could conceivably have an app that changes databases mid-execution, but in the general case it is used globally.

As for state, I don't think I need to argue the case that a database contains state.

So what makes a database different from the "bad" kind of global state?

This question came up because I'm trying to avoid tight-coupling where an object needs to know about its parent.

For example, say you're playing a strategy game, and one of your units have an ability that says when it deals damage to an enemy unit, that unit's owner loses x gold where x is 开发者_开发问答the amount of damage dealt.

Well, under normal circumstances, a unit shouldn't have to know who it's owner is. The owner is the one controlling the unit, so the owner just issues commands to the unit and it does its thing.

However because of external factors, there becomes a need to find out who the owner of a unit is. In this case, the attacking unit knows the unit it is attacking, that's fine. But now in addition to knowing the unit it's attacking it must further know it's owner in order to cause the owner to lose 5 gold.

I've already diverged more from the original question than I intended, but if the state of the game was stored in a relational database it would be trivial to query for the owner of the target without units needing to know directly who their owner was. If such a database were an object, I would call that database a god-object in the sense that it knows the entire state of everything, and additionally is mutable.

What then makes a database different from global state?

What makes it different is that it is designed as a shared global state resource.

A RDBMS implements ACID, which most other global state doesn't.

You could equally ask, "Why isn't an operating system considered a form of global state?" I guess depending on how you want to look at it, it is. But who cares? It's not the kind of global state that causes so many problems, namely global variables in library code. Both databases and operating systems are enabling technologies for a huge variety of programs--they've proven their worth. This is not to say either is without its problems: databases can make unit testing more difficult (hint: try mocks), and the wide variety of operating systems can make it difficult to make a program that everyone can use equally well.

Another way to look at it: there are valid alternatives to global state in most code, whereas the alternative to using a database would often be to effectively implement a database in your own code (whether you call it a database or not).

A dbms manages concurrent access, security, data integrity, and logical and physical data independence for multiple applications, regardless of their programming language, most of which might be unknown to an individual programmer. And it does all that generally in a simple, declarative way, not in a procedural way.

In the last Fortune 500 I worked at, programs written in at least 25 different languages hit our operational database. (From 'a' to 't', assembler to TCL. I don't recall any languages that started with the letters u through z, but there could have been some.) Some of those programs had their first release in the early 1970s.