楼主:
asleepme (500年没换暱称了)
2018-08-26 13:41:21请教dba神人，之前遇到一个应用情境是这样
我们有一组核心资料，跟2种服务
这2个服务(A、B)会用核心资料，去呈现不同的应用
所以A、B会有部分相同功能、部分不同功能
例如A会有功能 G、X、Y
B会有功能 H、X、Y
X、Y是一样的功能只是A情境下用，或是B情境下用
所以X、Y功能在db中需要的structure也是一样
A、B储存在X、Y里面的资料是互相独立的，没有任何关联
也就是说，在情境A下存进A.X的资料B完全不知道也没差
在这情况下，我们可以为A的X功能建立一个 A_func_X 的table
同样，B的X功能也可以建立一个 B_func_X 的table
但是这2个table的structure会一模一样
也可以A、B共用一个table func_X
里面有一个field叫type存A、或B，代表是哪个服务所建立的资料
想请教一下2种作法都适合吗？
会有什么后续要注意的状况？
作者:
alihue (wanda wanda)
2018-08-26 13:46:00你想一下，哪天A要客制B没有的功能。 然后B再客制会发生什么事情，该怎么设计就很清楚了
把那个field换一个make more sense 的名字，哪天服务就算名称换了也不会乱
作者:
alog (A肉哥)
2018-08-26 15:09:00看未来是否需要扩展新功能、资料量去决定怎么做额外增加一个字段其实也行但记得打好index不过要留意应用程式那边是否会有多余的开销，如果情境是大量/高度频繁使用时，A跟B日后有额外for A or B时的扩增容易在ORM初始化/SQL拉资料时有多余运算或传输开销(资料字段多或值的资料量大时会明显)得需要针对A跟B做个别的字段select(上述讲的是如果你之后共用一张表后来又加了only a or b字段的情况)白话一点就是，之后你可能有C D E F 日后你多加了 Only C的字段，其他 5 张表的相关程式再不做优化下通常都会初始化C跟拉C的字段资料尤其是你程式是别人在写时，大部分做的操作都是select * 这种一次拉全部 这种开销就是很明显资料量少其实没感觉 但是今天如果要拼同时在线、高并发情境或有必要优化时就要留意除非你上头的技术长还是主管有怪僻坚持不多开一张表 不然真的没有必要做太多纠结当然这个建议还是要视你的平台为主 毕竟跟网友比起来，你会比较清楚自己在弄的东西
资料不相关的情况下，我个人会选择拆表，省得麻烦，到时候有新人不懂domain where没下好资料就拉错，且测试上面每次都要验证清楚有没有拉到别边的资料
作者:
hua1040 (大米)
2018-08-26 18:28:00拆+1
作者:
jhnny (jhnny)
2018-08-26 19:42:00分开来...假设以后可能遇到A需要的字段B没有.或反之
作者:
jej (晃奶大馬桶)
2018-08-26 21:02:00如果资料量每天都是百万起跳 分析一下主要执行的系统吧次要的系统用trigger分出去 免得有人用了烂sql整个系统死掉阿如果一个月都不到一万 反正规可以给你快速度阿如果table垮了不同执行单位 还是拆了吧 免得纠纷
楼主:
asleepme (500年没换暱称了)
2018-08-26 23:13:00感谢高手们经验分享～