代码之家 › 专栏 › 技术社区 › kosoant

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

design-patterns sql java

kosoant · 技术社区 · 16 年前

我目前正在开发一个web业务应用程序,该应用程序有许多实体(人、组织),其中包含大量联系信息,即多个邮政地址、电子邮件地址、电话号码等。

目前,数据库模式是这样的:persons表和organizations表一样有邮政地址列和电话号码列。这不是处理此事的好方法。

我已经阅读了c2 Wiki上的相关内容,其中有一些很好的讨论 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:标识符

Contact_information_id:引用联系人信息表

值:此字段的值

对于字符串等,以此类推。。。

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

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

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

4 回复 | 直到 13 年前

Jason Morrison 16 年前

你的设计是可行的,我和其他人一样喜欢规范化,但你真的必须在某个地方找到平衡点。所以首先,我认为你是对的,拥有像address1、address2、address3等字段……是不好的做法。如果你打算处理来自不同国家的许多不同类型的邮寄地址,那么抽象出各种地址类型可能是有意义的。

想想你想从系统中获取的数据——例如,有人会询问某个州或省的所有客户吗?那样的话,你的设计会很痛苦。

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

祝你好运,找到正确的平衡点!

Tom Leys 16 年前

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

在您走这条路之前,市场上有许多产品旨在将客户详细信息存储在SQL数据库中。最好是直接购买现成的产品并与之集成。然后,你所有的担忧都会被其他人解决,你可以专注于你的特定商业案例。

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

Tassos Bassoukos 16 年前

这不是一篇信息量很大的帖子;你看过vCard用户是如何处理同样的问题的吗?此外,要小心过度设计,你最终可能会 N3 .

AJ. 16 年前

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

除此之外。.. 我喜欢你的思维方式。我也做过类似的事情(尽管不是用地址)来处理动态模式。我遇到的问题是(正如您所指出的)提取内容的SQL变得复杂。另一个问题是,这种灵活性可能会导致意大利面条数据,就像你得到意大利面条代码一样。也就是说,表中内容的含义可能会变得模糊,因为你只能通过查看访问它的代码来理解它。

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

所以,简短的回答是:你必须称呼它。