作者asleepme (500年没换昵称了)
看板Soft_Job
标题[请益] db要分table还是用一个field分类
时间Sun Aug 26 13:41:21 2018
请教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种作法都适合吗？
会有什麽後续要注意的状况？
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 223.136.180.153
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1535262084.A.04D.html
1F：推 alihue: 你想一下，哪天A要客制B没有的功能。 然後B再客制会发生什 08/26 13:46
2F：→ alihue: 麽事情，该怎麽设计就很清楚了 08/26 13:46
3F：推 RunRun5566: 把那个field换一个make more sense 的名字，哪天服务 08/26 15:06
4F：→ RunRun5566: 就算名称换了也不会乱 08/26 15:06
5F：→ alog: 看未来是否需要扩展新功能、资料量去决定怎麽做 08/26 15:09
6F：推 alog: 额外增加一个栏位其实也行但记得打好index 08/26 15:14
以目前的情况，比较可能发生的是多一个C，然後有X、Y功能
如果有一天多一个 Z 功能，也应该会同时apply到A、B、C上
是说计画很可能不照计画发生就是...
这样看起来A、B有各自的table好像比较适合我的状况，不知道有没有误会？
刚刚在stackoverflow上看到一篇，如果你觉得是entity那建table
如果是attribute，那建field
follow这个原则，看起来也是建table？
※ 编辑: asleepme (223.136.180.153), 08/26/2018 15:19:23
7F：→ alog: 不过要留意应用程式那边是否会有多余的开销，如果情境是大量 08/26 15:21
8F：→ alog: /高度频繁使用时，A跟B日後有额外for A or B时的扩增容易在O 08/26 15:21
9F：→ alog: RM初始化/SQL拉资料时有多余运算或传输开销(资料栏位多或值 08/26 15:21
10F：→ alog: 的资料量大时会明显)得需要针对A跟B做个别的栏位select 08/26 15:21
11F：→ alog: (上述讲的是如果你之後共用一张表後来又加了only a or b栏 08/26 15:22
12F：→ alog: 位的情况) 08/26 15:22
13F：→ alog: 白话一点就是，之後你可能有C D E F 日後你多加了 Only C 08/26 15:30
14F：→ alog: 的栏位，其他 5 张表的相关程式再不做优化下通常都会初始 08/26 15:30
15F：→ alog: 化C跟拉C的栏位资料 08/26 15:30
16F：→ alog: 尤其是你程式是别人在写时，大部分做的操作都是select * 这 08/26 15:31
17F：→ alog: 种一次拉全部 这种开销就是很明显 08/26 15:31
18F：→ alog: 资料量少其实没感觉 但是今天如果要拼同时在线、高并发情境 08/26 15:33
19F：→ alog: 或有必要优化时就要留意 08/26 15:33
20F：→ alog: 除非你上头的技术长还是主管有怪僻坚持不多开一张表 不然真 08/26 15:35
21F：→ alog: 的没有必要做太多纠结 08/26 15:35
22F：→ alog: 当然这个建议还是要视你的平台为主 毕竟跟网友比起来，你会 08/26 15:36
23F：→ alog: 比较清楚自己在弄的东西 08/26 15:36
24F：推 ripple0129: 资料不相关的情况下，我个人会选择拆表，省得麻烦， 08/26 17:10
25F：→ ripple0129: 到时候有新人不懂domain where没下好资料就拉错，且 08/26 17:10
26F：→ ripple0129: 测试上面每次都要验证清楚有没有拉到别边的资料 08/26 17:10
27F：推 hua1040: 拆+1 08/26 18:28
28F：推 jhnny: 分开来...假设以後可能遇到A需要的栏位B没有.或反之 08/26 19:42
29F：推 jej: 如果资料量每天都是百万起跳 分析一下主要执行的系统吧 08/26 21:02
30F：→ jej: 次要的系统用trigger分出去 免得有人用了烂sql整个系统死掉 08/26 21:04
31F：→ jej: 阿如果一个月都不到一万 反正规可以给你快速度 08/26 21:05
32F：→ jej: 阿如果table垮了不同执行单位 还是拆了吧 免得纠纷 08/26 21:06
33F：推 backforward: 没有共用性干嘛放一起，又不是写程式 08/26 21:55
34F：→ asleepme: 感谢高手们经验分享～ 08/26 23:13