關系數據庫結構邏輯配置

Question

我將使用MySql RDBMS在服務器端開發一個關系數據庫。

由於此數據庫將包含許多信息，並且將有許多同時查詢，因此我想設置一種優化的結構，以避免在檢索數據時過程緩慢。

我的主表稱為“帳戶”，將包含有關用戶的名稱，姓氏等信息：

 TABLE 'account'

 ID - NAME - SURNAME - AGE

 Primary key -> 'ID'

第二個表將被稱為“文件”，並具有一個ID（引用account.id的外鍵），一個文件名和一個名為“ count”的列：

 TABLE 'file'

 ID - FILENAME - COUNT

 Primary key -> {'ID','FILENAME'}

 Foreign key -> 'ID' -> 'account.ID'

我的最后一個表稱為“訪問”，其結構如下：

 TABLE 'visit'

 ID - FILENAME - OPTION

 Primary key -> {'ID','FILENAME'}

 Foreign key -> 'ID' -> 'account.ID'
 Foreign key -> 'FILENAME' -> 'file.FILENAME'

雖然第一個表不會包含很多行，但是第二個表可能有幾千行，第三個表有數十萬行。

也許我錯了（我不是數據庫系統管理和優化方面的專家：D），但是如果我同時對具有這么多行並與其他表連接的'visit'表進行查詢，則過程可能會變慢。

這個結構好還是可以改善？

最后一個問題，當“訪問”表更新時，我是否可以使用“訪問”中包含的行數自動更新“文件”->“計數”列，其中“ file.filename” =“ visit.filename”？

還是每次都進行類似“ SELECT ecc .. SELECT count（*）”的查詢更好？

希望我自己解釋一下，謝謝。

Answer 1

根據您的評論，您的想法聽上去不錯，但是一切都取決於業務，即業務邏輯-如果您考慮進行每日報告，幾周，每月訪問； 如果企業有興趣了解過去10、20或30年的訪問歷史。 以此為基礎，您可以不定期創建具有一定時間段（可能是一年）的歷史數據表。

如您所見，有很多方法，並且還應考慮技術方面的業務部分（例如磁盤空間，備份等），保留歷史數據有多重要以及保留多長時間。

編輯 ：

關於第二個問題，是的，如果您實現觸發器，則可以。 但是您可以檢查此鏈接，以確保您是否在決定創建觸發器方面做出了正確的決定。 （我不喜歡復制和粘貼，所以我更喜歡共享鏈接，如果我違反規則，請告訴我）

https://softwareengineering.stackexchange.com/questions/123074/sql-triggers-and-when-or-when-not-to-use-them

更新V.2.0：

意見建議：

1. 嘗試不要在列名（例如count，option）上使用受限名稱， 我不完全 了解mysql是否受限制， 但在SQL SERVER中是yes ，因此 為了可移植性 最好不要使用這樣的名稱。

2. 就像喬納森·萊夫勒（Jonathan Leffler）所說的那樣，保存年齡並不是一個好主意，您更喜歡保存生日。