2

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

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

我在这里关注“数字”地址。即一种线型地址。phone=ccc ccc ccc ccc 等 由于在这种情况下，物理地址在要求方面是相当标准的，因此用户将不得不使用给定的内容（位置、邮政、交付）以保持范围可管理。

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

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

1000, "电话", "ccc ccc ccc ccc", phoneformatter

1000, "facebook", "myfacebook", facebookformatter

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

  1. 读取后需要额外处理的 json blob（ContactId，地址）

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

或者是其他东西。

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

我主要关心的是用户的灵活性，但性能是其中的一个关键考虑因素。所以我不知道，只是做任何事情，然后扔一堆硬件；）

应用程序在 C# 中，如果这对后查询处理有任何影响。

4

2 回答 2

1

我不会选择 JSON blob。如果您需要回答以下任何问题，这将是令人讨厌的：-

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

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

您的附加解决方案几乎是正确的，但是 FormatterId 需要位于 AddressType 表上。您拥有的内容未标准化，因为 FormatterId 仅取决于 AddressTypeId。所以你会有三张桌子： -

  • 接触
  • 联系地址
  • 地址类型

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

于 2013-06-19T06:10:52.073 回答
0

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

contact(contactid, contact details, other details)

现在您想从联系人表中删除此联系方式，因为联系方式可能包含数字地址、电话号码等。

但是你正在考虑的表

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

如果您对每种类型的数字地址都有单独的表，并且对contactID进行索引，那就更好了

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

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

希望这会有所帮助:)

于 2013-06-19T05:38:38.410 回答