數據庫要求關係

Question

在微軟零售管理系統，如果我們檢查數據庫，它並沒有使用以下關係中的任何一個：

一對一

一對多

多對多

一位專家對我說，有時候關係是有害的，因爲它對我們的日常生活是有害的。所以在生活和數據庫中避免關係。我仍然認爲這是一個笑話。

的話，請告訴我，什麼是真正需要使用的關係，甚至我們還可以通過查詢等

Answer 1

關係（ER模型）是很好的，因爲他們描述你的模型管理同樣的事情 - 只是簡單地說，你可以當它們彼此連接時，更容易看到哪些實體相互關聯。

至於如果關係應該有一個外鍵（存儲模型），那麼答案是：這取決於。

這取決於什麼是關係的本質。在我工作的公司中，我們遵循以下規則： 僅在用戶定義的實體（對於對他有意義的關係，如客戶訂單）之間創建FK，避免系統自動添加的實體（如日誌/審計項目，特別是如果有很多項目）。

如果您有外鍵，刪除實體時可能會影響性能，因爲數據庫必須檢查此實體是否「未在使用」。這需要執行適當的select語句的時間。

Answer 2

relational-database s和entity-relationship完全沒有關係。

關係數據庫由組成關係的一組或多組事實組成。在這個模型中，一個關係只不過是一系列使相同「種類」聲明的事實。爲了確保數據庫中表示的一組事實是有效的，通常會有一些額外的約束條件適用於事實可以表示的方式。首先，事實必須是可識別的，每個事實應該有一個「關鍵」，並且對於任何可能的關鍵只有一個這樣的事實。另一個是，當一個事實對另一個事實提出主張時，肯定是所謂的（重複的）事實存在並且同意這個「元事實」。

作爲上述示例，您肯定不希望處於您知道「客戶10的付款時間比他們晚15天」的情況，但您不知道哪個客戶10是後面的客戶，因爲它們不止一個，或者根本沒有顧客10。這些限制有助於強制數據庫「一致」。

---

另一方面，實體關係只在應用程序設計方面有意義。這是描述抽象程序組件如何相互關聯的「語言」。關係數據庫通過函數依賴的方式提供了對這個「是 - 是」，「有 - 多」，「從屬於」類型的設計進行建模的方式，但它絕不是唯一的。另一個例子是在面向對象設計中使用的繼承和組合。

重要的是，一個應用程序可能有幾個類，它們彼此充分獨立，不需要組合或繼承，同樣，數據庫可能沒有功能依賴關係，但仍然是一致的。

也就是說，這樣的應用程序可能既小又不尋常;這些工具爲設計「良好」應用程序的任務提供了一些重要價值，幾乎所有工具都會對這些工具進行一些並可能廣泛的使用。