万能数据库设计方法探索
近日负责公司统一用户中心的数据库表结构设计,在工作过程中,诞生了一些另类的想法,特分享出来,期待大家拍砖。
公司主营业务:成都网站设计、成都做网站、移动网站开发等业务。帮助企业客户真正实现互联网宣传,提高企业的竞争能力。创新互联是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化,感谢他们对我们的高要求,感谢他们从不同领域给我们带来的挑战,让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联推出乐至免费做网站回馈大家。
思想的演化过程如下。
第一阶段:
将企业、机构、家庭等实体抽象为“组织”,Organization,简称 “O”,允许多级组织,通过parentId关联;
将部门等组织下属分支实体抽象为“部门”,Department,简称“D”,允许多级部门,通过parentId关联;
将自然人实体抽象为“自然人”,Human,简称“H”;
抽象出“账户”,Account,简称“A”;
抽象出“角色”,Role,简称“R”。
每一个组织允许拥有多个部门;每一个组织允许拥有多个自然人;每一个部门允许拥有多个自然人。
每一个组织、部门、自然人,都允许拥有多个账户。
账户可以共享多个角色。
第一阶段E-R关系如图
这是一个非常简单清晰的模型。
遗憾,真实世界不会如此简单。
第二阶段:
通过对产品业务的深入了解,需求变更为:
一个组织拥有多个部门,但同时一个部门可以从属于多个组织。(例:两个独立经营的连锁药店,共享同一个仓储部门。)
一个部门拥有多个自然人,但一个自然人可以从属于多个部门。(例:一个公司的总经理,兼职多个重要部门的部门经理。)
一个组织拥有多个自然人,但一个自然人可以从属于多个组织。(例:一个医生,可以多点执业。)
第二阶段E-R关系如图
现在还算是正常情况。
第三阶段:
新增一个简单的功能——邮政收货地址。
这是一个简单功能,但此次复杂之处在于:业务上,到底是“组织拥有收货地址?部门拥有收货地址?自然人拥有收货地址?还是账户拥有收货地址?各实体与收货地址,是一对一,还是一对多的关系?”这些问题,产品无法确定未来的功能扩展方向,只能回答“都有可能”。哈哈。。。
按照常规方法设计,为组织、部门、自然人、账户与收货地址之间,两两添加多对多关系表。关系表的数量开始膨胀,如同一个果园里,杂草数量比果蔬的数量都要多。。。
为了减少杂草数量,设计了一种抽象杂草:
添加实体(组织、部门、自然人、账户)与邮政地址的关系,由实体枚举code与实体id两个值,决定真实实体;由邮政收货地址Id,决定收货地址。
例如:
实体枚举code O, 实体id 1,邮政收货地址id 10,表示:id为1的某个组织,拥有id为10的某个收货地址。
实体枚举code H, 实体id 2,邮政收货地址id 20,表示:id为2的某个自然人,拥有id为20的某个收货地址。
实体枚举code A, 实体id 3,邮政收货地址id 30,表示:id为3的某个账户,拥有id为30的某个收货地址。
第三阶段E-R关系如图
第四阶段:
此时公司高层加入需求讨论,
A、要求对数据的控制颗粒度应该达到单条数据,并且可能要根据数据与周边任意实体的关系,进行权限控制,但是具体需求不定,要求做最大弹性设计。
B、追加资质管理、效期管理等功能,业务同样不知道未来的扩展方向在哪里,要求做最大弹性设计。
于是,抽象杂草的数量也开始膨胀起来。
针对需求A,设计了OneId表,将所有实体的Id在表中备份,未来一旦进行数据行级权限控制,通过OneId表进行关系扩展。
而为了让抽象杂草的数量不膨胀,设计了万用关系表,设计如下:
万用关系表 | |||
实体枚举code | 实体Id | 实体枚举code | 实体Id |
举例
万用关系表 | |||
实体枚举code | 实体Id | 实体枚举code | 实体Id |
O | 1 | H | 10 |
O | 1 | H | 11 |
H | 10 | A | 100 |
H | 10 | A | 101 |
上述数据,描述了
“Id为1的某个组织,拥有id为10、11的两个自然人”;
“Id为10的某个自然人,拥有id为100、101的两个账户”。
任何复杂的/未定的多对多关系,都可以用此万用关系表进行描述。
整个数据库设计最终版变化为:
注意:无论未来业务如何扩展,关系如何变化,仅需要扩展新的实体即可,不用再考虑与其他实体的关系,对历史设计不会产生任何冲击。
这是一种背离了所有现行数据库设计范式,简单万能的数据库设计方法,Universal DB Design Method,UDDM,简称犹大方法吧,感觉很贴切。
对上述设计方法,我的团队内部已没有足够的能力去评判正误,期待大家踊跃拍砖、共同探索。
本文名称:万能数据库设计方法探索
分享网址:http://azwzsj.com/article/gjggge.html