聯繫人的可擴展數據庫模式（社交）

我有一個需要升級的舊應用程序。現在不是一切都好嗎？聯繫人的可擴展數據庫模式（社交）

現有的數據庫模式由預定義的字段組成，如電話，傳真，電子郵件。很顯然，隨着過去5 - 7年（或更長時間取決於您所在國家）的社會爆炸式增長，終端用戶需要更多地控制他們認爲合適的方式創建聯繫人卡片，而不僅僅是我認爲可能有用的方式。

我在這裏關注「數字」地址。即一個線路類型地址。電話= ccc ccc ccc ccc等因爲在這種情況下物理地址在需求方面非常標準，用戶將不得不使用他們給定的位置（郵政地址，郵遞地址），以保持範圍的可管理性。

所以我想知道什麼是存儲數字信息的最佳實踐格式。對我來說，好像我有兩個選擇：

一個簡單的4場表（使用ContactID，AddressTypeId，地址，FormatterId）

1000，「手機」，「CCC CCC CCC CCC」， phoneformatter

1000，「臉譜」，「myfacebook」，facebookformatter

這將隨後在任何地方加入了它的需求。儘管表格會變得龐大，但隨着時間的推移，我認爲加入表現會降低。

一個JSON團塊這將需要一次讀取的附加處理（的ContactID，地址）

1000，{{ 「電話」：「CCC CCC CCC CCC」}，{ 「臉譜」：「myfacebook」}}

或...別的東西。

這個數據庫用於客戶在特定國家的國內交易，客戶羣範圍從3000-12000個賬戶，然後每個賬戶有多個聯繫人 - 當前系統的平均值約爲10。

我主要關心的是用戶的靈活性，但性能是一個關鍵的考慮因素。所以我不知道，只是做任何事情，並在其中扔硬件堆;）

應用程序是在C＃中，如果有任何區別重新：後處理查詢。

來源

2013-06-19 rism

您正在使用哪些DBMS？ Postgres的？甲骨文？ –

@a_horse_with_no_name一路Sql Server。 – rism

由於記錄數量很少，而且屬性的靈活性（「地址類型」）很自然，因此自然選擇是某種EAV模型（如第一個片段中的那個） – wildplasser

我不會去JSON blob。這將是討厭的，如果你需要回答任何疑問，如： -

有沒有人有我在他們的Facebook聯繫人？
什麼是最流行的社交媒體聯繫方式？

您將被迫爲每個記錄解析JSON並且無法創建簡單索引。

您的其他解決方案几乎是正確的，但FormatterId需要位於AddressType表上。你有什麼不規範，因爲FormatterId只取決於AddressTypeId。所以，你將有三個表： -

聯繫
ContactAddress
地址類型

，如果你需要存儲的相同類型的兩個地址針對單個聯繫人您還沒有規定。例如如果有人有兩個Twitter帳戶。回答此問題將允許您在ContactAddress上定義正確的主鍵。如果每個聯繫人只能有一種類型或創建一個合成密鑰（ContactAddressId），它可以是（ContactId，AddressTypeId）。

來源

2013-06-19 06:10:52

我認爲用jSon我可以使用一些全文查詢（Sql Server）來解答你的問題點問題。由於文本格式將會被很好地理解，所以我認爲我可以製作出很好的東西......我從來沒有。同時考慮將整個數據層轉移到EF ....是否會影響您的答案？兩個相同的聲音是合理的用例實際上取決於用戶首選項，我不明白爲什麼我不應該爲此支持，這幾乎沒有任何額外的努力。 – rism

在我看來，使用JSON依然是一個糟糕的主意。我有一個類似的列（除了XML），查詢和更新是很痛苦的。由於數據庫沒有強制約束，因此創建錯誤數據很容易。 –

好吧，我相信你有一個表指定的聯繫人

contact(contactid, contact details, other details)

，現在你想從通訊錄中刪除此聯繫方式，因爲聯繫方式可能包含數字地址，電話號碼和所有。

但表你正在考慮

(ContactId, AddressTypeId, Address, FormatterId)不正常的形式，你不能唯一標識一個元組，直到你讀所有的四列這是壞的，在這種情況下，索引也不會幫助你。

所以，如果你有，如果對每種類型的數字地址的單獨的表，並且對使用ContactID

facebookdetails(contactid, rest of the details) 
phonedetails(contactid, rest of the details)

索引和隨後的查詢都可以參加所有的表，也不會降低性能更好。

希望這會幫助:)

來源

2013-06-19 05:38:38 codeomnitrix

對不起，但這是一個可怕的想法。然後，而不是場爆炸我會有桌爆炸..問題的本質是不知道用戶希望存儲多少種不同類型的社會/數字地址。所以我不可能爲每個地址創建一個表「type」使用我概述的第一個方法只需要使用兩個字段到特定的地址contactid和addresstype，儘管通常id會返回大於1的結果集。 – rism

聯繫人的可擴展數據庫模式（社交）

回答

相關問題