为什么数据库不被视为全局状态的一种形式？
我对这种差异有一种普遍的直觉，但我无法准确指出是什么使数据库与全局状态不同。
根据“全局状态”的简单定义，数据库通常至少是应用程序全局的。您可以想象有一个在执行过程中更改数据库的应用程序，但在一般情况下它是全局使用的。
至于状态，我认为我不需要争论数据库包含状态的情况。
那么是什么让数据库不同于“坏”的全局状态呢？
出现这个问题是因为我试图避免对象需要了解其父对象的紧耦合。
例如，假设您正在玩一款策略游戏，并且您的一个单位具有一种能力，表示当它对敌方单位造成伤害时，该单位的所有者会损失 x 金币，其中 x 是造成的伤害量。
嗯，在正常情况下，一个单位不应该知道它的所有者是谁。所有者是控制该装置的人，因此所有者只需向该装置发出命令，它就会执行其任务。
然而，由于外部因素，需要查明单位的业主是谁。在这种情况下，攻击单位知道它正在攻击的单位，这很好。但现在除了知道它正在攻击的单位之外，它还必须知道它的所有者才能导致所有者损失 5 金币。
我已经偏离了最初的问题，超出了我的预期，但如果游戏的状态存储在关系数据库中，那么查询目标的所有者将很简单，而无需单位直接知道其所有者是谁。如果这样的数据库是一个对象，我会称该数据库为神对象，因为它知道所有事物的整个状态，而且是可变的。
那么是什么让数据库与全局状态不同呢？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
它的不同之处在于它被设计为共享的全局状态资源。
RDBMS 实现了 ACID，而大多数其他全局状态则没有。
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).
dbms 管理多个应用程序的并发访问、安全性、数据完整性以及逻辑和物理数据独立性，无论其编程语言如何，其中大多数可能对于单个程序员来说是未知的。它通常以简单的、声明性的方式而不是程序性的方式完成所有这些工作。
在我上一次工作的《财富 500 强》中，用至少 25 种不同语言编写的程序进入了我们的运营数据库。 （从“a”到“t”，从汇编程序到 TCL。我不记得任何以字母 u 到 z 开头的语言，但可能有一些.) 其中一些程序在 20 世纪 70 年代初首次发布。
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.