應該如何為社交平台設計邏輯數據模型，還是跳過它？
在學習了 George Tillmann 的一本書“使用驅動的數據庫設計：從邏輯數據建模到物理模式定義”之後。
我想為我自己的社交平台創建一個邏輯模型，該模型類似於具有自己風格的部落格平台。然而，在繪製邏輯模型時，很難決定什麼是它自己的實體和關係。本書中的大多數範例都顯示了與現實世界實體的“映射”，即已經存在的所有實體，即部門到工人，而不是我的網站，它有更多的人為分離。
例如，我必須決定“使用者”、“公共個人資料”、“使用者定義的類別”、“評論”、“喜歡”、“文章”之間的關係。問題是，我可以找到它們之間的關係。即評論是由使用者發表的，評論可以放在公共檔案中，評論在文章中，評論有喜歡，等等其他實體。如您所見，區別並不像現實世界的映射那樣突出。這個映射正常嗎？除非，我應該更具體..like profile-comment 連結到配置文件和使用者，post-comment 連結到文章和使用者，postlikes 連結到文章和使用者，commentlikes 喜歡評論和使用者。這裡仍然有一個星形模式。如果我添加一個“通知記錄器”實體，更糟糕的是，這裡幾乎所有地方都與它相關聯！
我現在覺得，在沒有邏輯模型的情況下創建一個實際的物理模型會更容易，但我不想錯誤地認為可以跳過——因為我缺乏建構模型的能力。
George Tillmann 對要遵循的框架的建議：
我個人從未正式創建過邏輯模型/邏輯模式，而不僅僅是從最終使用者那裡收集的一些預先計劃和資訊和需求。因此，這大致解釋了您從 George Tillmann 提供的圖中邏輯建模的前兩個步驟，而不是實際建構邏輯模型。
我喜歡開始動手，並在數據庫中建構物理實體及其關係。根據需要對它們進行更改很容易，尤其是在它們被發佈到生產環境之前，尤其是在它們中有任何實際數據之前。擁有物理模式可以很容易地視覺化，然後在短期內根據需要進行修改。
當人們難以定義模型時，我的一般建議是從根本上向後工作並考慮最終使用者需要的案例，然後考慮應用程序中需要支持它的具體類。您的數據模型在設計上通常與具體類本身相距不遠，尤其是在最常見的案例中，例如您的部落格平台。
此外，當您的大多數模型本身相互關聯時，本質上並沒有錯。一方面，這是一件好事，因為它表明您在關係模型中具有很強的引用完整性，使其適合關係數據庫。
並不是每個實體都與您的案例直接相關，例如，您不能
like（public-profile通常）在部落格中。相反，這兩個實體具有擴展關係，其中 apublic-profile與 auserwholikesa相關post。