[请益] 关于关联式数据库处理重复架构的方式

楼主: f0921048125 (Nagao)   2022-12-21 14:22:20
最近在开发功能的时候
有遇到一个满困扰的问题
在某些需求中,可能会遇到数张结构相同的表,
只是因为外来键参考的表不一样而分化
比如说有个纪录县市总预算的需求
假设县和市都有自己的东西要存,因此不能存在同一张表
必须是独立的两张表
那数据库预算表可能会长这样
CountyBudget
id/countyId/income/expenses
CityBudget
id/cityId/income/expenses
在程式面或许可以把预算表的属性抽一个物件
在县市底下放这个物件进去
但数据库这边除了重复定义字段之外 有其他方式可以解决吗?
有想过类似这样的方式
Budget
id/type/referId/income/expenses
但是问题是这样就没办法建立实体关联了QQ
作者: qss05 (minami)   2022-12-21 14:33:00
要关连可以两个自己不同type去关连啊?然后再建一个city跟country的关联,三个表就可以互串,照理,你原本也会建一个city-country的才对?不然你怎么关联的,除非你两个ID都一样?
作者: s06yji3 (阿南)   2022-12-21 15:07:00
你把budget的key分别放到county和city呀不一定要设定foreign key
作者: t64141 (榕树)   2022-12-21 16:18:00
两张额外的 mapping 表ㄧ端分别对应 county 和 city,另一端对应 budget 表。但会变成多对多且关联起来不方便,要在 mapping 表加 constraint 来避免多对多,不然就是如楼上放弃外键
作者: WaterLengend (Leeeeeeeeooooooo)   2022-12-21 17:06:00
那看起来就是把foreign key跟分散好几张表的column统一在一张table就好了,就是楼上大大的做法还是说参考foreign key的table可能会出现例外?
作者: s06yji3 (阿南)   2022-12-21 18:35:00
既然这样,我会把city和county不同的地方抽出分别建立两个表。共同的地方一个表再去关联预算。
作者: BlueBird5566 (生日56)   2022-12-21 18:44:00
用jpa来说 你要的是DiscriminatorColumn跟DiscriminatorValue你的字段会是 ID/TYPE/ID/INCOME/EXPENSES
作者: internetms52 (Oaide)   2022-12-21 19:07:00
既然要独立budget表,应该要各自拥有与county及city的关连表,麻烦的点是不想帮不同外键的表建立关连表吗?,这取决于这些外键与budget的关系是否一致,若一致,你是可以直接把全部的外键放在同一张表,只用单张关联表描述他
作者: SHANGOYANYI (彦一)   2022-12-21 19:41:00
呃 弄张表有region_type跟region_id不就好了?
作者: qss05 (minami)   2022-12-21 20:17:00
建一个对应表,看你想怎么关连budget的ID,budget只存ID/INCOME/EXPENSES,也是可以?
作者: alan3100 (BOSS)   2022-12-21 22:10:00
这年头还有人硬删除呀也太可怕了
作者: pvq212 (pvq212)   2022-12-21 23:25:00
多重多对多
作者: ck237 (白色小鸡)   2022-12-22 02:07:00
我是觉得多对多挺适合处理这个场景,把城市直接当一个菜单处理
作者: TAKADO (朕没给的你不能抢)   2022-12-22 09:14:00
用type+id,让persistence层自己去关联就好,资料维护时的完整性用别的方式处理,DB设计有时候要取舍,太追求理想化的schema有时候反而会造成更多问题。
作者: neo5277 (I am an agent of chaos)   2022-12-22 12:01:00
可能硬删除之后搬去hist吧
作者: acgotaku (otaku)   2022-12-22 12:23:00
我偏好CityBudget,CountyBudget分两张存除非你budget要常常混再一起算,不然你还要搞 M-to-M 表现在大型系统,不偏好这种作法 不利于扩展或是重构譬如到时候需求变更county has many cities的时候只需要算county budget总和,city budget只是county展开你原先做的多对多mapping table就会很难重构
作者: s860134 (s860134)   2022-12-22 14:30:00
典型的正规化/反正规化选择?
作者: yyc1217 (somo)   2022-12-22 17:08:00
我会分两张表 没必要为了省空间搞这么麻烦
作者: DrTech (竹科管理处网军研发人员)   2022-12-22 17:15:00
分两张表+1。书本上的各种 NF都太理想化。实际上不实用。
作者: qss05 (minami)   2022-12-22 23:14:00
正规化有好有坏啦,好处是串连的时候很灵活,可以只挑你要的资料,但有时候一个参数就要串3、4个表,但都不正规化也很烦,明明一样的参数,每个表都要存,如果又没有统一的命名规则,明明看起来一样,但命名不一样,就不知道有没有延伸意思,我之前待的两个公司就是这两个的极端…
作者: Hitmear (尸殌化液)   2022-12-22 23:25:00
怎么没人提到宽表?都塞一起就好
作者: ChungLi5566 (中坜56哥)   2022-12-23 08:31:00
看资料笔数 如果千万笔以下的话随便啦
作者: timTan (用口头禅区分年记)   2022-12-23 23:53:00
这应该是分表比较好。
作者: brucetu (sec)   2022-12-24 22:29:00
追求完美正规化只代表你的资料量根本不大捞个资料要跨好几张表
作者: cathychg (凯西)   2022-12-25 01:41:00
重复架构是什么。 @@DD ERdiagram 正规化 就三个重点资料关连图 切正规化 。。一对多 多对一。多对多 很口能出现 bug 大部分还是一对多 正规化 然后画关连图 之后个表格需要视窗化。。。有的不用这叫大学理论基础视窗化的功能 阳春的 慢慢逐步调整到完整的 跟专案时程有关譬如说 进销存系统 客户名单 产品代号 产品品项 客户订单 库存管理都是设计的内容视窗系统的页面要提供什么资料 这专案经理与工程师要讨论的订便当系统 可以看看 功能很阳春 但是该有的都有了那问题是。 server 是架设在那 稳定度呢? 餐饮业是门槛低的 高门槛的 呢…你确定你们考过大学吗?你确定学有专精嘛?你确定资深同事可以理解每个人的特质派与不同的任务完成专业能力等级高的专案吗每个人的特质与特长不同 所学的也不同 有的专长在法律系那简直一厢情愿的要硬凑在一起啊法律系 会计系 就去屎嘛问题在于 一个国科会的案子 不是国家重点的研发团队 那怎么类比第一个公司 那叫包山包海 接下来就是纯软 或专门infra那原本生技业的受到的牵连就越来越少成大有医学院啊…成大电机有电工实习 如果真的有上过电工实习的化包山包海的国家型计画不可能的资管系 应该是基础中的基础了 我没作弊 靠自己上大学的包山包海的国家级预算与计画 才可以吃掉那样多人力 现在不可能
作者: lchcoding   2022-12-25 08:39:00
楼上是不是回错篇阿!

Links booklink

Contact Us: admin [ a t ] ucptt.com