如何設計以下數據庫模型？

Question

我正在創建一個包含多個實體的系統，這些實體具有一些常用屬性，如名稱，電話號碼和地址等。另一方面，這些實體具有一些不常見的屬性。

使其更清晰的實體有：飯店，醫院，診所，藥店，醫療實驗室，工匠，該系統的設計是一個排名系統，這些隊伍和評論由用戶輸入。

換句話說，我需要實現另一個yelp.com系統。

我的問題是如何設計數據庫以優化搜索和易用性的方式？

我是否需要爲每個實體使用不同的表格，還是有辦法讓一個系統處理所有的實體。

Answer 1

• 如果你已經決定使用像SQL服務器或MySQL和 一個RDBMS還是希望有一個反規範化的結構，你可以嘗試 Entity-Attribute-Value Model。也有這個問題，上市這種類型的模型的優缺點：

  Entity Attribute Value Database vs. strict Relational Model Ecommerce

---

• 如果您還沒有固定的關係數據庫，我建議你讀 約NoSQL數據庫，如MongoDB和CouchDB。

Answer 2

它已經大肆宣傳，但CQRS可以defenitly幫助你在這裏。只是閱讀和研究它會讓你更好的準備，如果你不使用純CQRS去（無論是）

的關鍵，以優化搜索是

• 沒有加入

  關係數據庫當然知道它的連接，但是您可以通過「denormalisation」來最小化它們以加快查詢的速度

• 有最佳索引可能

  請閱讀幾本書，討論索引的來龍去脈。這裏的最好的建議是賺了指數覆蓋查詢，因此不必加入任何

如果你真的需要向外擴展（而不是向上擴展），這意味着你想僅僅通過以提高性能添加機器，您需要閱讀有關noSQL數據庫，因爲它們允許分片並且都是關於不加入的。我不太瞭解他們如何使用搜索以外的搜索行爲（由於分片非常快）。雖然缺乏對ad hoq報告的良好支持，但您需要調查/實驗/驗證概念。

Answer 3

我假設你已經決定了關係數據庫，因爲你在你的標籤中指出了SQL Server，並且你所問的模型是你所描述問題的表格設計。

在數據庫設計中有很多關於繼承的討論，有些是discussed here。

我會說，除非這些實體真的很相似，否則在公共表中分享諸如名稱之類的東西是沒有意義的。另一方面，如果您需要一組地理座標和一個圖標類型以顯示在地圖上，那麼該集合顯然可以跨越實體類型。還有一種可以解決與UNION在查詢的時候，所以它也許不應該是你的首要設計原則，除非地理學是你的應用程序的一個主要方面，即使這樣，一個可以簡單地拆分地理位置到它自己的表與索引合適。

我會先爲您的不同實體制定所有屬性，然後確定哪些屬性非常相似。其中一些將非常相似，以至於它們將與類型指示器列在同一個表中。例如，您列出的醫院和診所 - 我無法想象，除非你有關於服務或分部門廣泛的細節，甚至那麼我期待有一個診所，簡直是在其相關的條目較少醫院，這些將有很多的差異服務或部門表。

我會對不常見性質的性質更感興趣，因爲除非它們非常廣泛，否則所有這些實體似乎都在同一張表中。由於關係數據建模的第一步是首先識別所有屬性數據，然後確定與候選關鍵字的關係，我會首先看到關於收集屬性的信息，然後查看它們之間存在多少差異。

優化搜索是要取決於你的搜索是如何定義的。例如，如果您按位置進行搜索，則可能只會爲您的實體標記城域區域或完整的地理位置。有索引可以幫助您搜索距離某個位置的距離。如果您只需要選擇某些類型的實體，則可以確保您的索引包含該列。在這一點上，反規範化不會像索引那樣幫助您進行搜索，而是覆蓋查詢。當結果集很大時，非規範化效果最佳。搜索的重點是爲用戶提供結果集，根據定義，這些結果集對於他們能夠發現它們有用而言必須很小。對於一個用戶來說，1000個餐館的列表是沒有用的，因爲他們只能在一天中少量食用。

就易用性而言，我假設您正在談論從編程的角度來看易用性。如果您最終獲得了EAV模型，則可以通過使用視圖使查詢更加容易。如果你有一個單一的實體表，但想要更簡單的方法來獲得醫院，視圖可以提供幫助，只是因爲你有一個特定的底層數據庫模型，你仍然可以用不同的方式將它呈現給系統的其他層次，而這些並不總是必要引入大量的性能問題，因爲優化器可以在享有很好地工作（只要他們沒有遇到他們已經很難周圍工作狀集合體，其阻止他們能夠作爲輕鬆地重新排列他們的東西）。