理解，left join 后面增加and本身就是基本的SQL语法，我们也有很多客户开发ERP、CRM、OMS系统等，你在论坛 ...
好的，谢谢 关于你描述中的这段话：“入库主表一般有一个入库类型字段，保存着每个企业自己的类型如【采购入库、外包入库、固定资产入库、委外加工入库、维修入库】等，选择入库类型后，明细表上面有选择单据的按钮（选择入库类型对应的单据），采购入库就是选择采购订单表，委外加工入库就是选择委外加工业务表，以此类推。所以现在采购部门这边要在采购订单列表里显示出当前采购订单的入库数，他们要核对，委外加工部门也要在他们加工列表显示入库数，那就要先关联入库明细表，应为订单ID在入库明细表里，再关联入库表，入库表left join 入库表 on 入库明细表.入库表ID = 入库表.id and 入库表.入库类型 = 采购订单入库。”
类比我们库存管理系统demo中的架构，也是可以支持类似效果的，也不会出现你描述的情况。
在你的描述中，你加上on 的条件，目的就是为了，对于同样的表格，让采购入库的负责部门，在采购入库的界面只能看到采购入库的数据；让委外加工入库的负责部分，只能看到委外加工入库的入库数据。
这个你可以使用行权限，让采购相关角色只能看到目标类型的数据，委外加工入库的相关角色只能看到委外加工入库类型的订单，这样就可以了。希望我们能从系统实现的角度来考虑问题，不要一定局限于，用on这个方法对不对。活字格本身的产品属性中，就是有很多灵活的能力，不同的客户有不同的思路，有习惯的、不习惯的做法，这很正常，只要能实现我们的业务目标，也不复杂，就可以了。
Patrick.Zhu 发表于 2024-3-7 16:47
关于你描述中的这段话：“入库主表一般有一个入库类型字段，保存着每个企业自己的类型如【采购入库、外包入 ...
left join后面and条件没办法实现得话就算了，我们是用这个平台去替换老系统的，不是新开发系统，那我们公司先不考虑替换的事了，后面有新客户再拿这个平台重新开发，所以业务都分开再分表好了 从你梳理的信息来看，对每个类型都新建视图很多，但实际上视图结构都是类似的，复杂度并不高。而且这些视图也比较稳定，变动不会太多，很难讲有很大的运维压力，而且对于代码开发，同样的内容大概率也是需要维护相同的视图的，这是数据表结构的问题，并不是说切到活字格带来的额外压力。
如果真的希望直接切，你还可以写点存储过程，直接把数据批量改了，规范下数据。这类情况在使用中也是常见的，很多时候系统规划确实也跟不上业务变化，改个几百万条数据的标识字段也是常有的。 Patrick.Zhu 发表于 2024-3-8 09:05
从你梳理的信息来看，对每个类型都新建视图很多，但实际上视图结构都是类似的，复杂度并不高。而且这些视图 ...
视图的逻辑是先查出所有数据后再来筛选条件所以我们公司是禁用视图的，以后数据量大了对系统运维是一个考验。再就是我们还有第三方开发出来的报表，修改表结构那报表系统也全部要重新调整，所以我们不可能为了这个来增加我们的工作量，我们后期再考虑用活字格产品替换老系统吧，现在就先考虑后面的新客户了 {:5_111:}
页:
1
[2]