本文探讨了数据库管理系统(DBMS)中表间关系的设计原则。通过分析USERS与BILLING_DETAILS两个表之间的关系，阐述了为何选择特定的外键参照方式，并讨论了不同设计方案对软件系统的影响。
DBMS里的一些"自圆其说"(2)
书接 前回,上次提出了这样的问题:对于USERS和BILLING_DETAILS两个表,为什么非要把"USER_ID varchar(15) foreign key references USERS"放在BILLING_DETAILS表里?反过来行不行?也就是说在USERS表里加这个语句BILLING_DETAILS_ID foreign key references BILLING_DETAILS来替代.
这样的替代在语法上绝对没问题,那为什么不替代呢?替代了后会有什么不良后果呢?
我觉得这得从实际情况说起.
在实际生活中,USERS表所对应的Object是行动的主体,而BILLING_DETAILS所对应的Object完全处于从属关系.也就是说User可以有BILLING_DETAIL,也可以没有,若没有BILLING_DETAIL,一个User作为Object存在还是有意义的,这样的有意义反映有表间关系上就是在BILLING_DETAILS表里USER_ID要去references USERS;再反过来看时若用BILLING_DETAILS_ID foreign key references BILLING_DETAILS这样的引用关系,就是说BILLING_DETAILS表所对应的Object是主体了,一个BILLING_DETAIL可以不User也可以没有User,这样大多数情况下是不成立的.毕竟User的人是万物之首嘛,再说现在是Billing_Detail,也只有人才会发生这个Billing,从这个Billing身上也看出来那种正常的references关系.其实若仔细想想,那些少数的情况也是很容易找到的,仓库管理时的物件是以自身为主体了.
说了半天,现在更明白一点了:表间关系是整个软件系统所描述对象的映射,只不过在由DBA做这种映射处理时会根据实际情况(对象间关系的侧重点,查询性能优化...)translate成DDL的不同描述而已.
这也是传统的Buttom-up的软件建模情景,现在有了OO后,再加上Persistence的自动建表功能,是不是DBA的工作就被取代了呢?或在Persistence自动建表完成后,DBA再审查下,做下Tuning?
书接 前回,上次提出了这样的问题:对于USERS和BILLING_DETAILS两个表,为什么非要把"USER_ID varchar(15) foreign key references USERS"放在BILLING_DETAILS表里?反过来行不行?也就是说在USERS表里加这个语句BILLING_DETAILS_ID foreign key references BILLING_DETAILS来替代.
这样的替代在语法上绝对没问题,那为什么不替代呢?替代了后会有什么不良后果呢?
我觉得这得从实际情况说起.
在实际生活中,USERS表所对应的Object是行动的主体,而BILLING_DETAILS所对应的Object完全处于从属关系.也就是说User可以有BILLING_DETAIL,也可以没有,若没有BILLING_DETAIL,一个User作为Object存在还是有意义的,这样的有意义反映有表间关系上就是在BILLING_DETAILS表里USER_ID要去references USERS;再反过来看时若用BILLING_DETAILS_ID foreign key references BILLING_DETAILS这样的引用关系,就是说BILLING_DETAILS表所对应的Object是主体了,一个BILLING_DETAIL可以不User也可以没有User,这样大多数情况下是不成立的.毕竟User的人是万物之首嘛,再说现在是Billing_Detail,也只有人才会发生这个Billing,从这个Billing身上也看出来那种正常的references关系.其实若仔细想想,那些少数的情况也是很容易找到的,仓库管理时的物件是以自身为主体了.
说了半天,现在更明白一点了:表间关系是整个软件系统所描述对象的映射,只不过在由DBA做这种映射处理时会根据实际情况(对象间关系的侧重点,查询性能优化...)translate成DDL的不同描述而已.
这也是传统的Buttom-up的软件建模情景,现在有了OO后,再加上Persistence的自动建表功能,是不是DBA的工作就被取代了呢?或在Persistence自动建表完成后,DBA再审查下,做下Tuning?
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
