我的 ER 圖正確嗎？為什麼要使用關係？
這是我第一次為將在 MySQL 上建構的數據庫製作實體關係圖 (ERD)。相關的業務領域是設備問題管理。
在此之前，我永遠不會在表之間創建關係，我只會在 MySQLAdmin 中創建表並在我的 PHP/MySQL 程式碼中進行連結。
我有理由創建這些關係嗎？
我已經閱讀了很多關於數據庫設計和關係的資訊。
我想確保我創建的 ERD 是正確的；我犯錯了嗎？還是有更好的方法來做到這一點？
正在考慮的 ERD
我的數據庫應該做什麼：
- 我有一個可以創建票證（issue_tickets）的使用者（使用者）列表。
- 他們會給出問題的描述，可能會添加一些文件（issue_files）。
- 然後將附加其他使用者（issue_watchers）來解決問題。
- 所有使用者（users）都可以對一張票（issue_tickets）發表評論。
- 一張票 (issue_tickets) 一次只有一個狀態 (issue_status)。
- 一張票 (issue_tickets) 只有一個類別 (issue_category)。
- 一張票 (issue_tickets) 可以有許多評論 (issue_comments) 和許多觀察者 (issue_watchers)
- 一張票 (issue_tickets) 只有一個創建票的使用者（使用者）。
- 一張票（issue_tickets）只適用於一個設備（設備）。
- 一個使用者可以創建多個工單
- 一個設備可以有很多票
期望從應用程序中維護 PK/FK 關係是一種非常糟糕的做法。在任何重要的數據庫中，數據都有接近 100% 的機會從其他來源更改，包括臨時查詢、數據導入等。這是不負責任的認為數據庫中的數據受到保護，因為應用程序具有保護。當然，您認為您將通過 Web 服務或類似的方式強制進行所有更改，但現實情況是，沒有人會從您剛購買的那家公司添加一百萬條新客戶記錄，通過服務一次一條記錄。您的數據庫的設計必須考慮到人們會直接從源頭或通過其他應用程序（其中一些可能無法使用您的 Web 服務）更改它的事實。此外，應用程序介面通常比數據更容易被丟棄或重新設計，當這種情況發生時，您可能會失去全部或部分數據完整性規則。在設計數據庫時，您必須考慮隨著時間的推移如何保護數據，而不是考慮對程序員或初始應用程序來說最簡單和最方便的方法。數據專業人員在數據庫中設置 PK/FK 關係，因為這是數據所在的位置，並且是設置它以保護數據質量的最佳位置。
在我目前的職位上，我看到了許多不同公司的數據，我看到太多沒有在數據庫中建立 PK/FK 關係的公司，因為它們存在正確設計的數據庫不會出現的數據完整性問題。
您的 EER 圖符合您在設計中記錄的所有業務規則：
a) 您需要跟踪工單上的操作，即打開工單的時間、添加觀察者的時間、狀態更改的時間等以進行審核
b) 列命名 - 您使用 users_id throught，但每個外鍵應根據用途命名，例如： - issue_tickets - created_by 或 submit_by - issue_comments - submit_by
c) 表格命名 - 這只是我的風格，但我建議使用單數、issue_ticket 等命名表格