作者f0921048125 (Nagao)
看板Soft_Job
标题[请益] 关於关联式资料库处理重复架构的方式
时间Wed Dec 21 14:22:20 2022
最近在开发功能的时候
有遇到一个满困扰的问题
在某些需求中，可能会遇到数张结构相同的表，
只是因为外来键参考的表不一样而分化
比如说有个纪录县市总预算的需求
假设县和市都有自己的东西要存，因此不能存在同一张表
必须是独立的两张表
那资料库预算表可能会长这样
CountyBudget
id/countyId/income/expenses
CityBudget
id/cityId/income/expenses
在程式面或许可以把预算表的属性抽一个物件
在县市底下放这个物件进去
但资料库这边除了重复定义栏位之外 有其他方式可以解决吗?
有想过类似这样的方式
Budget
id/type/referId/income/expenses
但是问题是这样就没办法建立实体关联了QQ
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 220.134.113.80 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1671603742.A.79A.html
1F：→ qss05: 要关连可以两个自己不同type去关连啊？然後再建一个city跟12/21 14:33
2F：→ qss05: country的关联，三个表就可以互串，照理，你原本也会建一12/21 14:33
3F：→ qss05: 个city-country的才对？不然你怎麽关联的，除非你两个ID都12/21 14:33
4F：→ qss05: 一样？12/21 14:33
我上面只是举个例子 实际上有些情况是city和country并没有关联性 所以也没有关联表
可以直接参照
目前的做法就是在city和country底下各自建立一张budget表
但这种方式在遇到budget表底下也有很多与其关联的表
维护上就会十分麻烦...
以MSSQL来讲 应该是做不到type/referId，可以和不同的表做关联吧?
※ 编辑: f0921048125 (220.134.113.80 台湾), 12/21/2022 14:49:26
※ 编辑: f0921048125 (220.134.113.80 台湾), 12/21/2022 14:51:13
5F：推 s06yji3: 你把budget的key分别放到county和city呀12/21 15:07
6F：推 s06yji3: 不一定要设定foreign key12/21 15:11
7F：→ t64141: 两张额外的 mapping 表ㄧ端分别对应 county 和 city，另12/21 16:18
8F：→ t64141: 一端对应 budget 表。但会变成多对多且关联起来不方便，12/21 16:18
9F：→ t64141: 要在 mapping 表加 constraint 来避免多对多，不然就是如12/21 16:18
10F：→ t64141: 楼上放弃外键12/21 16:18
11F：推 WaterLengend: 那看起来就是把foreign key跟分散好几张表的column12/21 17:06
12F：→ WaterLengend: 统一在一张table就好了，就是楼上大大的做法12/21 17:06
13F：→ WaterLengend: 还是说参考foreign key的table可能会出现例外？12/21 17:07
我们有用On Delete的惯例
因此很少会选择放弃实体关联
※ 编辑: f0921048125 (111.83.165.50 台湾), 12/21/2022 18:20:19
14F：推 s06yji3: 既然这样，我会把city和county不同的地方抽出分别建立两 12/21 18:35
15F：→ s06yji3: 个表。共同的地方一个表再去关联预算。 12/21 18:35
16F：→ BlueBird5566: 用jpa来说 你要的是DiscriminatorColumn跟 12/21 18:44
17F：→ BlueBird5566: DiscriminatorValue 12/21 18:44
18F：→ BlueBird5566: 你的栏位会是 ID/TYPE/ID/INCOME/EXPENSES 12/21 18:45
19F：推 internetms52: 既然要独立budget表，应该要各自拥有与county及cit 12/21 19:07
20F：→ internetms52: y的关连表，麻烦的点是不想帮不同外键的表建立关连 12/21 19:07
21F：→ internetms52: 表吗?，这取决於这些外键与budget的关系是否一致， 12/21 19:07
22F：→ internetms52: 若一致，你是可以直接把全部的外键放在同一张表， 12/21 19:07
23F：→ internetms52: 只用单张关联表描述他 12/21 19:07
24F：推 SHANGOYANYI: 呃 弄张表有region_type跟region_id不就好了？ 12/21 19:41
25F：推 qss05: 建一个对应表，看你想怎麽关连budget的ID，budget只存ID/I 12/21 20:17
26F：→ qss05: NCOME/EXPENSES，也是可以？ 12/21 20:17
27F：→ alan3100: 这年头还有人硬删除呀也太可怕了 12/21 22:10
28F：推 pvq212: 多重多对多 12/21 23:25
29F：推 ck237: 我是觉得多对多挺适合处理这个场景，把城市直接当一个菜单 12/22 02:07
30F：→ ck237: 处理 12/22 02:07
31F：推 TAKADO: 用type+id，让persistence层自己去关联就好，资料维护时的 12/22 09:14
32F：→ TAKADO: 完整性用别的方式处理，DB设计有时候要取舍，太追求理想化 12/22 09:14
33F：→ TAKADO: 的schema有时候反而会造成更多问题。 12/22 09:14
34F：推 neo5277: 可能硬删除之後搬去hist吧 12/22 12:01
35F：→ acgotaku: 我偏好CityBudget,CountyBudget分两张存 12/22 12:23
36F：→ acgotaku: 除非你budget要常常混再一起算,不然你还要搞 M-to-M 表 12/22 12:24
37F：→ acgotaku: 现在大型系统,不偏好这种作法 不利於扩展或是重构 12/22 12:26
38F：→ acgotaku: 譬如到时候需求变更county has many cities的时候 12/22 12:45
39F：→ acgotaku: 只需要算county budget总和,city budget只是county展开 12/22 12:48
40F：→ acgotaku: 你原先做的多对多mapping table就会很难重构 12/22 12:50
41F：推 s860134: 典型的正规化/反正规化选择？ 12/22 14:30
42F：推 yyc1217: 我会分两张表 没必要为了省空间搞这麽麻烦 12/22 17:08
43F：→ DrTech: 分两张表+1。书本上的各种 NF都太理想化。实际上不实用。 12/22 17:15
44F：→ qss05: 正规化有好有坏啦，好处是串连的时候很灵活，可以只挑你要 12/22 23:14
45F：→ qss05: 的资料，但有时候一个参数就要串3、4个表，但都不正规化也 12/22 23:14
46F：→ qss05: 很烦，明明一样的参数，每个表都要存，如果又没有统一的命 12/22 23:14
47F：→ qss05: 名规则，明明看起来一样，但命名不一样，就不知道有没有延 12/22 23:14
48F：→ qss05: 伸意思，我之前待的两个公司就是这两个的极端… 12/22 23:14
49F：推 Hitmear: 怎麽没人提到宽表？都塞一起就好 12/22 23:25
50F：→ ChungLi5566: 看资料笔数 如果千万笔以下的话随便啦 12/23 08:31
51F：→ timTan: 这应该是分表比较好。 12/23 23:53
52F：→ brucetu: 追求完美正规化只代表你的资料量根本不大 12/24 22:29
53F：→ brucetu: 捞个资料要跨好几张表 12/24 22:30
54F：推 cathychg: 重复架构是什麽。 @@ 12/25 01:41
55F：→ cathychg: DD ERdiagram 正规化 就三个重点 12/25 01:43
56F：→ cathychg: 资料关连图 切正规化 。。一对多 多对一。 12/25 01:44
57F：推 cathychg: 多对多 很口能出现 bug 大部分还是一对多 正规化 然後画 12/25 01:45
58F：→ cathychg: 关连图 之後个表格需要视窗化。。。有的不用 12/25 01:45
59F：→ cathychg: 这叫大学理论基础 12/25 01:46
60F：→ cathychg: 视窗化的功能 阳春的 慢慢逐步调整到完整的 跟专案时程 12/25 01:47
61F：→ cathychg: 有关 12/25 01:47
62F：→ cathychg: 譬如说 进销存系统 客户名单 产品代号 产品品项 客户订 12/25 01:48
63F：→ cathychg: 单 库存管理都是设计的内容 12/25 01:48
64F：→ cathychg: 视窗系统的页面要提供什麽资料 这专案经理与工程师要讨 12/25 01:49
65F：→ cathychg: 论的 12/25 01:49
66F：→ cathychg: 订便当系统 可以看看 功能很阳春 但是该有的都有了 12/25 01:50
67F：推 cathychg: 那问题是。 server 是架设在那 稳定度呢？ 餐饮业是 12/25 01:51
68F：→ cathychg: 门槛低的 高门槛的 呢… 12/25 01:51
69F：推 cathychg: 你确定你们考过大学吗？你确定学有专精嘛？你确定资深同 12/25 01:53
70F：→ cathychg: 事可以理解每个人的特质派与不同的任务完成专业能力等 12/25 01:53
71F：→ cathychg: 级高的专案吗 12/25 01:53
72F：→ cathychg: 每个人的特质与特长不同 所学的也不同 有的专长在法律系 12/25 01:54
73F：→ cathychg: 那简直一厢情愿的要硬凑在一起啊 12/25 01:54
74F：→ cathychg: 法律系 会计系 就去屎嘛 12/25 01:55
75F：→ cathychg: 问题在於 一个国科会的案子 不是国家重点的研发团队 那 12/25 01:56
76F：→ cathychg: 怎麽类比 12/25 01:56
77F：→ cathychg: 第一个公司 那叫包山包海 接下来就是纯软 或专门infra 12/25 01:58
78F：→ cathychg: 那原本生技业的受到的牵连就越来越少 12/25 01:58
79F：→ cathychg: 成大有医学院啊… 12/25 01:58
80F：→ cathychg: 成大电机有电工实习 如果真的有上过电工实习的化 12/25 01:59
81F：→ cathychg: 包山包海的国家型计画不可能的 12/25 01:59
82F：推 cathychg: 资管系 应该是基础中的基础了 我没作弊 靠自己上大学的 12/25 02:01
83F：→ cathychg: 包山包海的国家级预算与计画 才可以吃掉那样多人力 现在 12/25 02:02
84F：→ cathychg: 不可能 12/25 02:02
85F：→ lchcoding: 楼上是不是回错篇阿！ 12/25 08:39