在ER建模中有哪些更好的實踐？

Question

我正在開發的技術支持Twitter的基於應用程序的公司

所以，工作流程大約是這樣的

1- Twitter的用戶提到的公司。

2-管理員得到通知。

3-開始與客戶一起使用DM。

所以，我對最佳ER模型有點困惑。

我是否應該將tweets和DM存儲在同一張表中，還是應該將它們分開，以獲取數千條記錄？

Answer 1

你的模型有幾個實體，USER_ID表示用戶的誰寫的鳴叫ID：

基本結構

Message (id, message, user_id, date etc) 
User (id, name, employee_id?, etc) 

單一賬戶提到

然後你有事實上可能會發生，這是一個消息的屬性，所以你可以添加一個像這樣的列：BOOL提到，如果你只想有一個acco UNT。將給：

Message (id, message, user_id, date, BOOL mentioned, etc) 
User (id, name, employee?, etc) 

多個帳戶可以提到

另一種形式可以更加靈活，加上它允許存儲的提到你想要的賬目表帳戶：

Account (id, name) 
Message (id, message, user_id, date, INT account_mentioned, etc) 
User (id, name, employee?, etc) 

這給了更多的靈活性，因爲您可以添加一個賬戶並開始跟隨提及，例如可以通知該賬戶的管理員，使您的解決方案更具前瞻性。

如何處理與員工

根據您的工作流程，你可以說：員工是處理一個或多個帳戶的用戶。你也可以說一個賬戶由多個用戶管理，最後是多個用戶管理多個賬戶的情況。

從本質上講，我建議做一個連接表：

Accounts_Users (account_id, user_id) 

你甚至可以在表或例如優先級添加角色。這使您可以完全控制帳戶。因爲沒有給出這方面的信息，所以我不能一一解釋。

存儲DM的和公共的消息

然後你有DM的問題，這可能是最容易被添加到該消息的實體：

Account (id, name) 
Message (id, message, user_id, user_to_id (NULLABLE), date, INT account_mentioned_id, etc) 
User (id, name, employee?, etc) 

所以在默認情況下爲消息（鳴叫）user_to_id列是NULL，但是當它是DM時，您需要在其中添加接收者。這樣你可以找到它們。

爲什麼把他們都在一個表？它是具有相同屬性的相同實體，它只有一個標誌（私有），但本質上是相同的數據。

數據

量......在這個階段完全無關。本質上你只需要正確的結構，所以首先要正確化。如果你真的看到性能問題，然後看看如何去規範一些步驟，但我不認爲，對於單個公司使用，你會遇到問題與此歸一化結構。

你只需要正常的簡單連接，以獲得您想要的數據，因爲它是歸你也可以很容易地創建例如顯示一個用戶（客戶端）的所有通信，因爲你歸一化的頁面。這個設置很容易得到這些數據。

我們有幾百萬辦理鳴叫，你可以直接歸，沒問題真的。數據不是很大，所以很多行並不昂貴。

最後的安裝建議

我會去根據我現在掌握的信息這種方式。

Account (id, name) 
Accounts_Users (account_id, user_id) 
Message (id, message, user_id, user_to_id (NULLABLE), date, account_mentioned_id, etc) 
User (id, name, etc)