Question

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

现有数据库架构由预定义字段组成，如电话，传真，电子邮件。显然，随着过去5 - 7年（或更长时间取决于您所在国家/地区）的社会爆炸，最终用户需要更多地控制以他们认为合适的方式创建联系卡，而不仅仅是我认为可能有用的。

我在这里关注“数字”地址。即一种线型地址。 phone = ccc ccc ccc ccc等由于物理地址在要求方面非常标准，因此用户必须使用它们所提供的内容（位置，邮政，交付），以保持范围可管理。

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

一个简单的4字段表（ContactId，AddressTypeId，Address，FormatterId）

1000，“phone”，“ccc ccc ccc ccc”，phoneformatter

1000，“facebook”，“myfacebook”，facebookformatter

然后在任何需要的地方加入。该表会变得很大，并且我怀疑连接性能会随着时间的推移而降低。

一旦读取（ContactId，地址）

1000，{{“phone”：“ccc ccc ccc ccc”}，{“facebook”：“myfacebook”}}

或......别的东西。

此数据库仅供客户在特定国家/地区使用，客户基础范围为3000-12000个帐户，然后每个帐户有多个联系人 - 当前系统平均约为10个。

我主要关注的是用户灵活性，但性能是其中的关键考虑因素。所以我不知道，只是做任何事情，并在其上投入大量硬件;）

应用程序在C＃中，如果这有任何区别：查询处理。

Answer 1

我不会去寻找JSON blob。如果你需要回答任何问题，这将是令人讨厌的： -

有没有人让我加入他们的Facebook联系人？
什么是最受欢迎的社交媒体联系方式？

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

您的其他解决方案几乎是正确的，但FormatterId需要位于AddressType表上。你没有规范化，因为FormatterId只依赖于AddressTypeId。所以你会有三个表： -

联系
ContactAddress
地址类型

您尚未声明是否需要针对单个联系人存储两个相同类型的地址。例如如果有人有两个Twitter帐户。回答此问题将允许您在ContactAddress上定义正确的主键。如果每个联系人只能拥有一种类型，或者创建一个合成密钥（ContactAddressId），它将是（ContactId，AddressTypeId）。

Answer 2

好吧，我相信你有一个名为contact

的表

contact(contactid, contact details, other details)

现在您要从联系人表格中删除此联系人详细信息，因为联系人详细信息可能包含数字地址，电话号码等。

但是你正在考虑的表

(ContactId, AddressTypeId, Address, FormatterId)不是正常形式，你不能唯一地识别一个元组，直到你读完所有四个不好的列，在这种情况下，索引也无法帮助你。

如果您为每种类型的数字地址设置单独的表，并在contactID上编制索引，那就更好了

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

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

希望这会有所帮助：）

联系人的可扩展数据库架构（社交）

2 个答案: