0

我目前正在开发一个 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：引用联系信息表
  • 值：该字段的值

    • 等等字符串等...

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

    我对 in SQL 的可行性表示怀疑。有什么想法吗？

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

    4

    4 回答 4

    1

    它开始听起来像你有一个非常好的锤子（即你的 SQL 数据库）并且你正试图用它做另一个锤子（一种用于定义 SQL 模式的元语言）。

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

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

    于 2008-09-17T07:52:22.967 回答
    1

    你的设计是可行的，我和下一个人一样非常喜欢规范化，但你真的必须在某个地方找到平衡。因此，首先，我认为拥有地址 1、地址 2、地址 3 等字段是正确的做法......是不好的做法。如果您计划处理来自不同国家的许多不同类型的邮寄地址，那么抽象出各种地址类型可能是有意义的。

    想想你想要从系统中取出的数据——例如，有人会询问某个州或省的所有客户吗？在这种情况下，您的设计将非常痛苦。

    要记住的另一件事是，数据库模式更改虽然有时会很痛苦，但并不是世界上最糟糕的事情。沿着这条路径走向它的逻辑极端，你最终会得到一个巨大的表，其中包含“key”和“value”等字段以及每个查询中的数千个自联接。

    祝你好运找到正确的平衡！

    于 2008-09-17T07:56:45.123 回答
    0

    First: Speaking pragmatically, it depends what you want to do with the data. In my experience, 99% of all address data is only ever used as a string to be printed on a letter. If that is the case for you, then you should stop worrying and just store it as a string. Of course, if you're doing deeper work with it then it's not going to be so easy.

    Apart from that... I like the way you're thinking. I have done similar things (although not with addresses) to handle dynamic schemas. The problem I run into is (as you've identified) that the SQL to extract the stuff gets complex. Another problem is that this flexibility can lead to spaghetti data, in exactly the same way you can get spaghetti code. I.e. the meaning of what's in your tables can become obscured because you can only understand it by looking at the code which accesses it.

    So, what you have to decide is where you are prepared to accept complexity, and what kind of complexity you can best handle. If you don't mind complex SQL, then go ahead and build your dynamic schema. If you do mind complex SQL, then either build the static tables (with one table per address type), or accept that you won't have such an elegant data structure.

    So, short answer: you have to call it.

    于 2008-09-17T08:57:00.220 回答
    0

    这不是一个信息量很大的帖子；您是否看过 vCard 人员如何处理相同的问题？另外，请注意过度工程，您最终可能会得到N3。

    于 2008-09-17T07:50:43.313 回答