各位大大好
小弟是一间小公司里
负责部分核心业务的软件工程师
为了日益多样的客群，被安排要规划新的设计
程式语言使用的是Java,数据库是Postgres
框架使用了Hibernate及Spring data JPA
有天CTO跟我说想到了个好方法
要把核心业务中
原本关系为多对一的A Table 与B Table
改为多对多关系
并把Key直接用String Array Type
储存在A Table的某个新字段里
这样一来就有很大的弹性
小弟做了一些功课
向CTO表达了应该加关系表正规化的想法
但CTO不满意，觉得关系表很多余
小弟又用String Array Type 在Java世界里
并没有完整支援为理由尝试说服
CTO却觉得这些都是可以克服的问题...
小弟认为一但使用String Array Type
并且不使用关系表
就很有可能要全部走Native SQL
日后无论延展需求或维护都会相当痛苦
为此非常苦恼
因为核心业务的复杂程度
小弟希望可以降低日后的维护门槛
想询问各位大大
String Array Type的问题
真的有这么好克服吗？
或是有什么更好的说服理由是小弟没想到的？
这是小弟首次于软件版发文
感谢耐心看完的大大们，献上万分的谢意

我的建议是不要怕留下技术债 还债的不一定是你

实际上正规化后各种限制也是问题

推1F，怕什么，你这专案成功了就丢给菜鸟维护了还能嘴他需求做太慢，你当年XX一天就好

你们业务逻辑里有没有需要从 B 反查 A?

CRPKT大大您好，主要的逻辑都是从B向A来查询的，是为了多个B对多个A才这样做的，因为1B对多A的关系不够用

存json字串 或是干脆nosql

关系表是有必要的，也可以用NOSQL，或是快逃不过根据主要业务来评估比较好，如果不频繁的话都行

需要这么厚工喔？ 一个基本多对多的表是难在哪?XD

不就一个mapping table就搞定是难在哪pk:id,A_pk,B_pk,isValid,modifyDatestring array或nosql 你都还是要面对是否要强一致性问题

你是要问怎样比较好，还是怎么说服你家CTO..如果要表达关系的话，关系表才是最简单又有弹性的，存个array除了不开新table外，既没好处也没什么很大的弹性啊

CTO的沟通部分也许跟软件不太有关，若觉得奇怪就留给小弟我自己解决就可以了，大大们就分享想分享的部分就好，谢谢各位大大的回复

有些情况是不太想用 join 两种方法各有优缺 有json type可以用

读写比例 预估资料总笔数 峰值流量 日常流量这些都会影响你要用哪种方式实作但有一个很简单的准则就是 如果你小公司 流量小就用写code最快的方式让memory去扛一切的问题你家CTO提出的办法基本上就是写code最快最懒的方法也就是最省成本建议你就做 万一效能爆炸 增加硬件成本 责任不在你

真的照你家CTO那想法做 那以后资料层问题是dev负责还是dba负责？

这种可以当CTO==?

用json/jsonb吧 反正他提出来的 出事就叫他自己去跟老板/客户解释

stackoverflow也有人问类似的问题，也有人提出解决方法，所以技术上不是问题，CTO则是考量公司营运未来所以所预先的规划，即使原PO不做也会找别人做，当然原PO不在意升迁、加薪、年终的话说自己不想负责这块看能不能请其他同事负责也行

又不是什么违背良心的事情XD

CTO不都是自家公司随便喊的吗。原PO就照做就好，不必争论，未来自己当CTO之后就可以做借镜了

如果只有几十万笔资料，爱怎么变就让他变，如果是几千万笔以上，要三思，pg的sql analyze很笨，更何况还要用array去拆，及做关联，explain你看看cost可能都是full table scan，cost可能就吓死人

那方法怎么会写code最快最懒，原po都说了用jpa hibernate关系表直接@ManyToMany就完了，array一定要用postgres的native sql去写，哪里省了好像有不少人包括一楼说技术债都以为是在说CTO提了个方便快速的方法，不是吧这篇明明是在抱怨CTO提了个程式就比较难写又不合常规、但也说不出哪里好(只说就有很大的弹性、关系表多余)，然后也没什么目的只为了少开个多余(?)table当然实际上也许CTO是有什么考量，但显然原PO没接收到

可怜喔，烂CTO搭配junior ，真是一绝

一楼精辟

一楼三楼是在自爆自己的为人吗? XD 不过一堆没讲的都是这样 环境真的不好言归正传 解法楼上都有人说了 用json postgres可提取json内的值 或者你取出来反序列化也可以 如果了解json本质 会觉得这格式很不错postgres有一些json_为前缀的函数

资料量不大或者存取不频繁就会以可维护性来考量。或者说追求一致。但是一旦资料量大，就要考虑join成本。这个时候就会认真考虑用json了jsonb是解multi-value的好工具

CTO CIO多的是 不是技术出身的咖 看多了啦

问他为啥要过度设计 有没有有潜在的需求会不会沟通这些东西往往就是junior senior的差别

还好吧 反正规化的一种而已 做正规化不等于比较好维护跟扩展 坦白说硬要正规化是有点过时的想法了

这不是过度设计 是实作方式不同 一致性与灵活性是可以兼得的 但市面上多半都是看到一致性强但改个小功能就很累的东西框架会加强一致性但也会缩限应用 巨无霸框架是灾难