作者littlethe (东周流浪汉)
看板Soft_Job
标题Re: [请益] db要分table还是用一个field分类
时间Tue Aug 28 22:15:30 2018
这其实在大学就会学到的观念了,
虽然我感觉大学的资料库很多人教得不太好,
教得太抽象很容易让人听不懂...
anyway,
以我判断,
这状况要拆成3张表,
甲表是共用field,
乙表是A情境用,
丙表是B情境用,
然後甲表和乙表做成view专门给A情境用,
甲表再和丙表做成view给B情境用,
举例子来讲会比较好懂,
我们要设计游戏,
游戏里有文官和将军,
将军没有行政属性,不能做行政职,
但有战斗属性,可以带兵,
文官有行政属性没战斗属性,可以做行政,但不能带兵,
所以我会先建一张表叫人物表,
表上有姓名,性别,生日等所有人物都有的属性
(当然这时候会有天兵用年龄当field而不是生日,这就要打屁股了)
另一张表叫将军表,
属性有人物id,可以join到人物表,
还有战斗能力,战斗经验值,
再一张表叫文官表,
属性有人物id,外交能力,内政能力,研究能力...
再把将军表和人物表变将军view,
文官表和人物表变文官view,
要为军队选择将军时,就读将军view,
要选内阁时,就读文官view,
要看人物列表时,就只读人物表,
当然会有人既是将军也是文官,例如凯末尔或艾森豪,
但在这种结构下,这种全才会同时存在将军与文官的view中,
所以不用担心
设计资料库的道理和OO有共同之处,
就是一个表,和一个field最好只有一个很明确的存在目的,
而且要尽量让结构可以很灵活的组合,
就像变形金钢一样可以变来变去,
如果一个表用来做一大堆事的话,
那就会变得很难维护了...一动就会扯到很多事,
细节前面与推文也很多人有讲了就不多说,
要注意的地方大概就是要看一张表的数据量会不会超大,
如果超过百万笔的话就要注意,
因为百万笔的表再join其他表的话,很可能有效能问题,
如果要让效能提升,
只做成2张表也行,各自应付A情境和B情境而不join,
就是所谓的反正规化,
但这样做的缺点是若要查A情境和B情境共同的东西时的话,
就得用union了,
如查人物列表,变成要文官表union将军表,
用field去把一个表模拟成两张表...
我目前是想不到这样做有什麽好处啦,
比较像是有人没受过资料库训练,
自己幻想出的solution,
等A情境需要加些field或key,
B情境也需要加些field或key,
再来个C情境要加些field,
你就会看到传说中的资料库大魔王表,一张有上百个field的表,
你就可以唱首歌,
"我们的table,一眼望不完~,数不完的fields,峰峰相连到天边~",
实务上我也碰过几次这种前人留下的资料表坑,
费了九牛二虎之力还不一定解决得完,
因为表用在正式系统後,就不能随便动了,动了容易出事,
所以会这样告诉你,
也发现虽然资料库大家都在用,
但很多人不太会设计,
有时候还真想去当老师教资料库
※ 引述《asleepme (500年没换昵称了)》之铭言：
: 请教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种作法都适合吗？
: 会有什麽後续要注意的状况？
--
18岁前,我沉迷於动漫,後来把动漫丢了,好好面对真实世界,
30岁後,我再度沉迷於动漫,只是是带着疲倦的心情,试着从中获取一丝快乐
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 118.212.136.26
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1535465769.A.1EB.html
※ 编辑: littlethe (115.238.194.35), 08/28/2018 22:41:14
1F：推 qa17b: 签名档有点悲伤 08/28 22:43
2F：推 bheegrl: 一丝快乐吗?推抗"游戏3人娘"，但是别在吃东西的时候看 08/28 22:51
3F：→ bheegrl: *坑 08/28 22:51
4F：推 t64141: 1没设计好的资料表要重构真的难 08/28 23:02
5F：→ johnny94: 最尴尬的是你正确设计还会被没学过的乱批评 08/28 23:51
6F：推 agogoman: 我看过中文讲资料库设计最深入浅出的是独孤木的那一个系 08/29 00:10
7F：→ agogoman: 列, 我都建议先看过那一系列然後再回头啃教科书, 相对会 08/29 00:11
8F：→ agogoman: 比较有感觉. 08/29 00:11
9F：推 TAKADO: 而且你去问乱设计的还会放大绝说 没差啦 这个有差吗？随便 08/29 01:03
10F：→ TAKADO: 啦 08/29 01:03
11F：推 jj092357q4e3: 情境想的颇有趣，给推 08/29 01:05
12F：→ littlethe: 因为怕被人取代呀,所以很多人宁可一直做错也不愿认错 08/29 01:15
13F：→ littlethe: 这也就是为什麽我不喜欢再去小公司了,因为小公司没钱 08/29 01:16
14F：→ littlethe: 请能力好的人,就请一堆基础很差自己摸出来的,就很容易 08/29 01:18
15F：→ littlethe: 将错就错,去攻击对的人,变成劣币趋逐良币,久了公司就变 08/29 01:20
16F：→ littlethe: 得很恐怖...看公司正不正常,真的看薪水就可以推测出来 08/29 01:21
17F：推 xdraculax: 推 08/29 02:17
18F：推 pzyc79: 我也是这麽想的 但是没办法像这样解释的这麽清楚 08/29 03:18
19F：→ littlethe: 看来常打电动的好处就是可以举出大家好理解的例子 08/29 03:31
※ 编辑: littlethe (115.238.194.35), 08/29/2018 03:55:32
20F：推 welcome0: 有时候会被ㄎㄅ说over design，但到了一定量就很难动啊. 08/29 09:47
21F：→ welcome0: .. 08/29 09:47
22F：推 iamyiz: 推。签名档qq 08/29 09:48
23F：推 johnny94: 有时候基本常识被说成是 over design 的情况也是很常见 08/29 10:23
24F：→ johnny94: 的 08/29 10:23
25F：推 a926: 老师教教窝 08/29 11:01
26F：推 ericsung: 一堆只会乱做又不承认自己错 也不愿改 懒得改 08/29 13:18
27F：→ littlethe: over design确实也会存在,但这很主观,不管是不是over 08/29 15:08
28F：→ littlethe: design,至少设计者要有设计资料库的观念,有观念,要补 08/29 15:09
29F：→ littlethe: 要修,要赶时间的话,也才知道要怎麽应对各种状况 08/29 15:11
30F：→ littlethe: 而不是呆呆的自己胡思乱想乱猜怎麽做 08/29 15:12
31F：→ realbout: 怪了 这不就是正规化的目的... 08/29 20:57
32F：推 THEWORLDS: dba太缺就是这样 遇到会弄得直接转出资料重弄一个才爽 08/29 22:54
33F：→ THEWORLDS: 乱搞成本有时候会多出好几E 不如花多点钱请一个好的DBA 08/29 22:55
34F：→ THEWORLDS: 不过台湾小公司大多是这样 15万打死 08/29 22:55
35F：→ littlethe: 但我发现很多公司没有请DBA的念头,也不知道正规化 08/30 01:54
36F：→ hakama99: 这情况我应该会拉两个表单 一个将领table 08/31 16:46
37F：→ hakama99: 一个将领能力表单 栏位有将军ID,type(军师,军人),能力 08/31 16:47
38F：→ hakama99: 文武官 08/31 16:49
39F：→ hakama99: 不然你的做法以後多一个宦官或其他类型的 就要多开表单 08/31 16:50
40F：→ hakama99: 仔细看了一下你说的才是对的 不同类型栏位会不同 SORRY~ 08/31 16:53
41F：推 zased: 这篇写得很好，感谢分享 09/01 03:57
42F：推 asleepme: +1 收益良多，值得收藏 XD 09/03 17:01