建议数据表操作命令的删除操作增加【级联删除】的选项设定

场景描述：当数据结构设计是主子表结构时（比如部门表 和部门小组子表），当在列表页面进行删除父表部门表的记录（选择多条同时删除），需要对子表部门小组表的记录也要级联删除掉。如图：


解决方法A：通过参考活字格的文档，如果利用活字格内置的数据库SQLLite建表的话，可以在表关系中设置主子表，并设置级联删除即可。
但是如果用的不是内置数据库，比如用SQLServer，就没法在活字格的数据表管理中愉快的设置这些东东了。。。。。。。

解决方法B：用页面的一个选择表格容器做过渡，删除时启用事务，先删子表，再删主表。如图：


但是B方案还是略显麻烦，因为要去增加个选择容器，还要再去写两个删除命令集成事务，其中还要注意提示是否删除确认框的顺序（只能显示一个）。
so，官方是否可考虑修改下这个数据表操作命令的删除部分，直接增加对级联删除的配置部分，例如级联删除的子表表名选择，以及对应的主子表的外键关联。

这个问题估计官方也想实现，只是对外联库的操作没那么容易，这个问题早有人提过了。

lwt 发表于 2019-10-15 20:13
这个问题估计官方也想实现，只是对外联库的操作没那么容易，这个问题早有人提过了。

应该并不困难呀
想象一下这个插件的执行和开发过程：
1. 插件UI部分增加 一个checkbox来标识是否启用级联删除子表，如果选定则出现  子表选择，目标表的关联字段  和 子表的关联字段。如下图：

PS 目标表关联字段 和子表的关联字段就是指父表和子表是通过各自的那个字段产生关联。
2. 这时更新记录有三个选择：当前行，特定行和选定行，不管哪个选项，我想活字格的最终操作机制都是将其转化成SQL语句的where部分，
当前行：也许活字格是得到当前行的id值，比如3，然后拼出的where语句就是  id=3；
特定行：这个比较明显，是根据选择的条件配置，拼出的sql的条件部分
选定行：这个猜测是通过js先得到选择行的id，拼接成例如id in (1,2,3) 这样的条件语句。
总之，不管怎么样，可以得到删除主表的sql语句：如 DELETE FROM tableMaster where id in (1,2,3) ，仅仅可得到，不执行，因为要先删除子表，再回过头删除主表
3. 如果选择级联删除子表，假设子表名是tableDetail，父表的关联字段是：pNo，子表对应的关联字段是mNo。 则应先拼出子表的删除语句：
DELETE FROM tableDetail WHERE mNo IN (SELECT pNo FROM tableMaster WHERE id IN (1,2,3))
PS 注意以上示例中WHERE id IN (1,2,3)的部分来自主表删除条件拼出的sql片段。如第二条所说。  其余的所有变量信息均取自UI的设置。
4.然后再执行主表的删除语句 DELETE FROM tableMaster where id in (1,2,3)
5.当然，为了事务安全，把这两个语句可以封装到事务中。
似乎就搞定了。。。。。。

我现在都是用设计器设计表，同时在子表中增加一个PID的字段，用于对接主表的ID，然后再到SQL里给每个子表增加外键，外键用子表PID关联主表ID，外键设置级联删除、级联更新，这样设置跟自带SQLITE里的级联删除和级联更新是一样的效果，就是麻烦点。
如果格子能在设计器里直接实现，就好了。而且子表的外键增加也是可以通过SQL语句来实现的，实现上无外乎根据数据库类型，然后执行一行SQL代码而已。

估计官方想的就是统一，方法也就是统一数据库的操作用外键处理。如果是如想直接抛sql语句云执行，应该是好操作些。

嗯，不太建议用数据库的外键机制来处理，因为可能涉及到不同数据库的处理模式的差异。直接根据指定的关键关系来生成sql应该是通用的

这个不好说，这个不同数据库之间差异太大了

差异大，可以先搞主流的啊，比如MSSQL用的人比较多吧，这个可以先完善起来啊！

作为活字格的用户，我个人觉得，B方案已经能很好的解决这个问题了。
另外，如果已经采用了 SQL Server的话，还是要更多的了解SQL语言，以及SQL Management studio，在SQL Management studio中，是可以设置外键约束，实现联接删除等操作的。
相信楼主应该也可以感受到，即使是SQL Management studio也包含了太多的功能，要把这些功能都集成到活字格，既不现实、也没有必要。

保持活字格功能的简洁性（不去包含过多，甚至是重复的功能），可以更好的兼顾广大用户的使用感受。嗯，套用乔帮主的的话说：  less is more！


以上，个人浅见，仅供参考

carl_chen 发表于 2019-10-19 15:17
作为活字格的用户，我个人觉得，B方案已经能很好的解决这个问题了。
另外，如果已经采用了 SQL Server的话 ...

那个，首先，我是不建议用数据库的级联以及外键特性来做级联删除的。因为这样对数据库设计结构会产生很大的依赖，这也是会导致因为不同的数据库对外键设置不同导致难以做到统一。 所以我是建议的插件封装操作时按照方案B来的，如我所说，是通过纯粹的SQL语句的拼接来完成的，我只是目前认为这个拼接可用T-SQL，应该是不同数据库产品通用的。 而并非建议将MSSQL的特性功能集成到活字格中来
其次，less is more是否可以理解为对终端用户对产品的感受而言？我以为活字格的功能应当是围绕如何降低用户技术门槛以及简化用户重复工作这两个核心来展开。比如活字格的用户，如果他们需要每次做这样主从关系的表是都需要重复的进行这些多道步骤，或者除了使用活字格，还要用SQL管理器，查询分析器.....等一系列工具之后才可以完成，那是会对用户的技能水平的需求是提高，而不是降低。因为如果产品简洁化是指产品本身而言，那活字格最简洁的做法是只需提供一个sql编辑器命令，用户自行编写相应的SQL即可，而不用去封装个表操作插件，数据操作命令等。
PS：市面上还真有这样的产品，这部分产品是专注于专业的代码开发者向SQL开发者简化。