联系人的可扩展数据库模式(社交)

Question

我有一个旧的应用程序需要升级。现在不是什么都有吗？

现有的DB模式由预定义的字段(如电话、传真、电子邮件)组成。显然，随着过去5-7年(或更长时间取决于你的国家)的社会爆炸，最终用户需要更多的控制，以他们认为合适的方式创建联系人卡，而不是我认为可能有用的东西。

我在这里关注“数字”地址。即一行类型地址。phone=ccc等，因为物理地址在需求方面是相当标准的，在这种情况下，用户将不得不使用给定的内容(位置、邮政、传递)来保持范围可管理。

所以我想知道存储数字信息的最佳实践格式是什么。在我看来，我有两个选择：

1. 一个简单的4个字段表(ContactId、AddressTypeId、Address、FormatterId)

1000，“电话”，"ccc ccc"，电话格式 1000，"facebook"，"myfacebook"，facebookformatter

这样就可以在任何需要的地方加入这一行列。不过，这张桌子会变得很大，而且我怀疑，join的性能会随着时间的推移而下降。

1. 一个json blob，一旦读取就需要额外的处理(ContactId，地址)

{“电话”："ccc ccc"}，{"facebook"："myfacebook"}}

或者..。一些其他的东西。

这个数据库适用于一个特定的国家，客户只在国内进行交易，客户基础从3000到12000帐户不等，然后每个账户有很多联系人--在目前的系统中，平均约有10个。

我主要关注的是用户的灵活性，但性能是其中的一个关键考虑因素。所以我不知道，只要做任何事，把一大堆硬件扔向它;)

应用程序在C#中，如果这有任何区别的话: re:后置查询处理。

Answer 1

我不会选择JSON blob。如果您需要回答以下任何问题，这将是非常糟糕的：-

• 有人在Facebook上联系过我吗？
• 什么是最受欢迎的社交媒体联系方式？

您将被迫为每个记录解析JSON，并且无法创建一个简单的索引。

您的附加解决方案几乎是正确的，但是FormatterId需要在AddressType表上。你所拥有的并没有正常化，因为FormatterId将只依赖于AddressTypeId。所以你有三张桌子：-

• 联系方式
• ContactAddress
• AddressType

您还没有说明是否需要针对单个联系人存储两个相同类型的地址。例如，如果某人有两个twitter帐户。回答这个问题将允许您在ContactAddress上定义正确的主键。如果每个联系人只能拥有一种类型，或者创建一个synthenic (ContactId，AddressTypeId) (ContactAddressId)，则可能是(ContactAddressId)。

Answer 2

嗯，我相信你有一张名叫联系人的桌子

contact(contactid, contact details, other details)

现在，您希望从联系人表中删除此联系人详细信息，因为联系人详细信息可能包含数字地址、电话号码和所有内容。

但是你正在考虑的那个桌子

(ContactId, AddressTypeId, Address, FormatterId)不是普通形式的，在读取所有四列(这是不好的)之前，您无法唯一地标识元组，在这种情况下，索引也不会对您有帮助。

因此，如果您对每种类型的数字地址都有if单独的表，并且在contactID上有索引，则更好。

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

然后查询可以连接所有表，它不会降低性能。

希望这会有所帮助:)