我目前正在开发一个Web业务应用程序,它有许多具有大量联系信息的实体(人员,组织),即。多个邮政地址,电子邮件地址,电话号码等。
目前,数据库架构使得人员表具有邮政地址列,电话号码列以及组织表。这不是解决这个问题的好方法。
我已经阅读了关于这个问题的c2维基,关于Contact and address models ( http://c2.com/cgi-bin/wiki?ContactAndAddressModels)以及是否physical addresses are archaic ( http://c2.com/cgi-bin/wiki?ArePhysicalPostalAddressesArchaic)有一些很好的讨论。这两个讨论真的让我看到了这个问题的范围。
我正在考虑将联系信息字段分隔为单独的表格。但是最好的方法是什么呢。目前,该应用程序主要处理芬兰地址,但它即将到来,它还需要处理国际地址。
我可以定义“地址”表格,“电话号码”表格,“电子邮件地址”表格等等,这些表格可以链接到人员和组织。但这只是感觉太像以前的解决方案:预定义的数据库模式不可避免。
我建议的是创建动态的联系信息架构/程序逻辑:
这可行吗?有人做过这样的事吗?
可能有一个表定义联系信息类型:
然后可以有一个表来定义每个联系信息类型使用的字段:
然后我们会有一个“联系信息表”,它只用于将联系信息字段映射到一起:
然后我们会有一个“人的联系信息” - 可以将不同的联系信息映射给人:
然后我们需要每个联系人信息字段类型的表格,如:
依此类推字符串......
最后,当显示给定人员的不同联系信息时,这将通过人员的联系信息 -table查找从联系信息类型字段<用于形成此联系信息的字段< / b> -table通过联系信息 -table。在确定使用了哪些字段之后,所有必要的表将连接在一起。
我对SQL的可行性表示怀疑。有什么想法吗?
在Java中,我可能编写一些逻辑来确定哪些表需要形成联系信息实体,然后我可以使用某种动态bean来表示Java中的这些数据。但这对我来说也有点模糊。对此也有任何想法?
答案 0 :(得分:1)
它开始听起来像你有一个非常好的锤子(即你的SQL数据库),你正试图用它来制作另一个锤子(一种定义SQL模式的元语言)。
在您走这条路之前,市场上有许多产品旨在将客户详细信息存储在SQL数据库中。最好只购买一个现成的并与之集成。然后,您所有的问题都由其他人解决,您可以专注于您的具体业务案例。
编辑:允许您添加自定义联系人字段的软件包的一个示例是SugarCRM - 它是一种商业产品,您可以在购买时购买对源的访问权限。我相信还有更多,但这是目前唯一想到的。
答案 1 :(得分:1)
你的设计是可行的,我和下一个人一样忠于标准化,但你真的必须找到一个平衡点。首先,我认为你拥有像address1,address2,address3等字段是对的,这是不好的做法。如果您计划处理来自不同国家/地区的许多不同类型的邮件地址,那么抽象出各种地址类型可能是有意义的。
考虑一下您想要离开系统的数据 - 例如,有人会要求某个州或省的所有客户吗?在这种情况下,你的设计将非常痛苦。
要记住的另一件事是数据库架构的变化,虽然它们有时会很痛苦,但并不是世界上最糟糕的事情。沿着这条道路走向它的逻辑极端,你最终会得到一个巨大的表格,其中包含“key”和“value”等字段以及每个查询中的数千个自连接。
祝你找到合适的平衡!
答案 2 :(得分:0)
这不是一篇内容丰富的文章;你看过vCard人员如何处理同样的问题了吗?另外,要注意过度工程,最终可能会使用N3。
答案 3 :(得分:0)
第一:务实地说,这取决于你想要对数据做什么。根据我的经验,99%的地址数据只用作字母打印的字符串。如果是这种情况,那么你应该停止担心并将其存储为字符串。当然,如果你正在做更深入的工作,那么它就不会那么容易了。
除此之外...... 我喜欢你的想法。我已经做了类似的事情(虽然没有地址)来处理动态模式。我遇到的问题是(正如你已经确定的那样)提取东西的SQL变得复杂。另一个问题是,这种灵活性可能导致意大利面条数据,与您获得意大利面条代码的方式完全相同。即表格中的内容的含义可能会变得模糊,因为您只能通过查看访问它的代码来理解它。
因此,您必须决定的是您准备接受复杂性的地方,以及您可以最好地处理的复杂性。如果您不介意复杂的SQL,那么继续构建您的动态模式。如果你介意复杂的SQL,那么要么构建静态表(每个地址类型有一个表),要么接受你不会有这样一个优雅的数据结构。
所以,简短回答:你必须打电话给它。