我目前正在开发一个具有许多实体(人员，组织)和许多联系信息的Web业务应用程序，例如。多个邮政地址，电子邮件地址，电话号码等。

目前，数据库架构是这样的：人员表与组织表一样具有邮政地址列，电话号码列。这不是处理此问题的好方法。

我已经阅读了c2 Wiki，并且关于联系人和地址模型(http://c2.com/cgi-bin/wiki?ContactAndAddressModels)进行了一些很好的讨论，而无论物理地址是否古老(http：// c2 .com / cgi-bin / wiki？ArePhysicalPostalAddressesArchaic)。这两个讨论确实使我对这个问题的范围大开眼界。

我正在考虑将联系信息字段分离为单独的表。但是，最好的方法是什么。目前，该应用程序主要处理芬兰地址，但它也需要处理国际地址。

我可以定义一个"地址"表，一个"电话号码"表，一个"电子邮件地址"表等等，这些都将链接到人员和组织。但这感觉太像以前的解决方案：不可避免的是，预定义的数据库架构是不够的。

我提议的是创建一个动态的联系信息模式/程序逻辑：

• 没有预定义的联系信息字段/字段集
• 瑞典邮政地址
• ... 邮寄地址
• 电话号码
• 电子邮件地址
• ICQ号

这可行吗？有人做过这样的事情吗？

可能会有一个表定义联系人信息类型：

联系信息类型

• ID：标识符
• 姓名："芬兰邮政地址"
• 说明："使用此联系信息类型作为芬兰的邮政地址"

然后可能有一个表，用于定义每种联系信息类型使用哪些字段：

联系信息类型字段

• ID：标识符
• Contact_information_type_id：引用上表
• 字段标题："地址行1"
• 字段说明："将此行用作邮政地址的第一行"
• 字段类型：字符串/整数/等。
• 字段格式：用于验证字段数据的正则表达式
• 字段顺序：显示/使用此联系信息类型时，该字段应以什么顺序出现

然后，我们将有一个"联系信息表"，该表仅用于将联系信息字段映射在一起：

联系信息

• ID：标识符
• Contact_information_type_id：引用联系人信息类型表

然后，我们将获得一个"人的联系信息"表，该表将不同的联系信息映射到人：

人的联系方式

• ID：标识符
• Contact_information_id：引用联系人信息表
• 人员ID：引用人员

然后，我们需要每种联系信息字段类型的表格，例如：

联系信息整数字段

• ID：标识符
• Contact_information_id：引用联系人信息表
• 值：此字段的值

以此类推字符串等等...

最终，当显示给定人员的不同联系人信息时，这将通过该人员的联系人信息表来发生，从而从联系人信息类型表到联系人信息表中查找用于形成此联系人信息的字段。确定使用了哪些字段后，所有必要的表将被连接在一起。

我对SQL的可行性存有疑问。有什么想法吗？

在Java中，我可能可以编程一些逻辑来确定需要哪些表来形成联系信息实体，然后可以使用某种动态bean来用Java表示此数据。但这对我也有点模糊。对此也有想法吗？

解决方案

回答

这不是一个非常有用的文章；我们是否看过vCard人员如何处理相同的问题？另外，请注意不要过度设计，否则可能会遇到N3.

回答

听起来好像我们有一个非常好的锤子(即SQL数据库)，并且我们正试图用它锤子(定义SQL模式的元语言)。

在走这条路之前，市场上有很多产品旨在将客户详细信息存储在SQL数据库中。最好只购买一个现成的产品并与之集成。然后，我们所遇到的所有问题都将由其他人解决，我们可以专注于特定的业务案例。

编辑：一个允许我们添加自定义联系人字段的软件包的示例是SugarCRM，它是一种商业产品，我们可以在其中购买购买的源。我敢肯定还有更多，但这是目前唯一想到的一个。

回答

设计是可行的，我和下一个家伙一样热衷于规范化，但是我们确实必须在某个地方找到一个平衡点。因此，一开始，我认为我们是对的，拥有诸如address1，address2，address3等字段是错误的做法。而且，如果我们打算处理来自不同国家/地区的许多不同类型的邮寄地址，则应抽象出各种地址类型。

考虑一下我们要从系统中获取的数据，例如，有人会要求某个州或者省的所有客户吗？在这种情况下，设计将非常痛苦。

要记住的另一件事是，尽管数据库架构更改有时可能会很痛苦，但这并不是世界上最糟糕的事情。沿着这条路走到逻辑上的极端，我们将最终得到一个巨大的表，其中包含诸如"键"和"值"之类的字段，并且每个查询中都有成千上万的自我联接。

祝我们找到合适的平衡！

回答

首先：务实地说，这取决于我们要对数据做什么。以我的经验，所有地址数据中的99％仅用作打印在字母上的字符串。如果我们是这种情况，那么我们应该不再担心，只需将其存储为字符串即可。当然，如果我们要对其进行更深入的研究，那将不会那么容易。

除此之外...
我喜欢你的想法。我已经做了类似的事情(尽管没有地址)来处理动态模式。我遇到的问题是(正如我们所确定的)提取内容的SQL很复杂。另一个问题是，这种灵活性可能导致获取意大利面条数据，这与获取意大利面条代码的方式完全相同。 IE。表中内容的含义可能会变得晦涩难懂，因为我们只能通过查看访问它的代码来理解它。

因此，我们必须决定要在哪里准备接受复杂性，以及可以最好地处理哪种复杂性。如果我们不介意复杂的SQL，请继续构建动态架构。如果我们确实介意复杂的SQL，则可以构建静态表(每种地址类型一个表)，或者接受我们不会拥有如此优雅的数据结构。

因此，简短的答案：我们必须调用它。