动态联系信息数据/设计模式:这是否可行?

时间:2008-09-17 07:43:33

标签: java sql design-patterns

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

目前,数据库架构使得人员表具有邮政地址列,电话号码列以及组织表。这不是解决这个问题的好方法。

我已经阅读了关于这个问题的c2维基,关于Contact and address models ( http://c2.com/cgi-bin/wiki?ContactAndAddressModels)以及是否physical addresses are archaic ( 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:Identifier
  •  
  • Contact_information_id:引用联系信息表
  •  
  • 值:此字段的值

  • 依此类推字符串......

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

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

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

    4 个答案:

    答案 0 :(得分:1)

    它开始听起来像你有一个非常好的锤子(即你的SQL数据库),你正试图用它来制作另一个锤子(一种定义SQL模式的元语言)。

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

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

    答案 1 :(得分:1)

    你的设计是可行的,我和下一个人一样忠于标准化,但你真的必须找到一个平衡点。首先,我认为你拥有像address1,address2,address3等字段是对的,这是不好的做法。如果您计划处理来自不同国家/地区的许多不同类型的邮件地址,那么抽象出各种地址类型可能是有意义的。

    考虑一下您想要离开系统的数据 - 例如,有人会要求某个州或省的所有客户吗?在这种情况下,你的设计将非常痛苦。

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

    祝你找到合适的平衡!

    答案 2 :(得分:0)

    这不是一篇内容丰富的文章;你看过vCard人员如何处理同样的问题了吗?另外,要注意过度工程,最终可能会使用N3

    答案 3 :(得分:0)

    第一:务实地说,这取决于你想要对数据做什么。根据我的经验,99%的地址数据只用作字母打印的字符串。如果是这种情况,那么你应该停止担心并将其存储为字符串。当然,如果你正在做更深入的工作,那么它就不会那么容易了。

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

    因此,您必须决定的是您准备接受复杂性的地方,以及您可以最好地处理的复杂性。如果您不介意复杂的SQL,那么继续构建您的动态模式。如果你介意复杂的SQL,那么要么构建静态表(每个地址类型有一个表),要么接受你不会有这样一个优雅的数据结构。

    所以,简短回答:你必须打电话给它。