爲什麼數據庫不是一種全局狀態？

Question

我對這個區別有一個總的直覺，但是我無法準確地確定是什麼使數據庫與全局狀態不同。

隨着「全局狀態」天真的定義，數據庫通常至少應用程序全局。你可以想象有一個應用程序可以在執行中改變數據庫，但在一般情況下，它是全局使用的。

至於狀態，我不認爲我需要認爲，一個數據庫包含狀態的情況。

那麼是什麼讓數據庫與「糟糕」的全局狀態不同呢？

這個問題上來，因爲我試圖避免緊耦合，其中一個對象需要知道它的母公司。例如，假設你正在玩策略遊戲，並且你的一個單位有能力說明它在對敵方單位造成傷害時，該單位的所有者失去了x金，其中x是受到的傷害量。

那麼，在正常情況下，單位不應該知道它是誰的所有者。擁有者是控制單位的人，所以擁有者只需向單位發出命令，它就可以完成任務。

但是，由於外部因素，需要找出誰是一個單位的所有者。在這種情況下，攻擊單位知道它正在攻擊的單位，沒關係。但是現在除了知道它所攻擊的單位之外，它還必須知道它是所有者，才能使所有者失去5金。

我已經從原始問題中分離出了比我想要的更多的東西，但是如果遊戲的狀態存儲在關係數據庫中，那麼查詢目標的所有者就會很簡單，而不需要直接知道誰他們的主人是。如果這樣的數據庫是一個對象，那麼我會將該數據庫稱爲上帝對象，因爲它知道所有事物的整個狀態，並且是可變的。

什麼使數據庫不同於全局狀態？

Answer 1

你也可以問：「爲什麼操作系統不被認爲是一種全局狀態？」我想根據你想看它的方式，它是。但誰在乎？這不是導致如此多問題的全局狀態，即庫代碼中的全局變量。數據庫和操作系統都爲各種各樣的程序提供了技術支持 - 它們證明了它們的價值。這並不是說沒有任何問題：數據庫可能會使單元測試更加困難（提示：嘗試模仿），而且各種各樣的操作系統可能會使難以製作一個每個人都可以同樣使用的程序。

查看它的另一種方式：在大多數代碼中，有全局狀態的替代方法，而使用數據庫的替代方案通常是在自己的代碼中有效實現數據庫（無論您是否將其稱爲數據庫） ）。

Answer 2

所不同的是，它是設計作爲共享全局狀態的資源。

一個RDBMS實現ACID，其中大部分全球其他國家沒有。

Answer 3

數據庫管理系統來管理多個應用程序併發訪問，安全性，數據完整性和邏輯和物理數據獨立性，無論他們的編程語言，其中大部分可能是未知的個人程序員。它通常以一種簡單的，陳述式的方式進行，而不是以程序方式進行。

在我工作的上一個「財富」500強中，用至少25種不同語言編寫的程序打擊了我們的運營數據庫。 （從'a'到't'，彙編到TCL，我不記得任何以或到或開頭的語言，但可能會有一些。）其中一些程序的第一個版本在七十年代初期。