团队开发了一款类似 ERP 的企业的业务管理系统对外售卖，数据约束（外键、触发器、存储过程等）是放在数据库层面，还是放在代码层面？
einsdisp · 2020-08-27 14:57:42 +08:00 · 2025 次点击这是一个创建于 1540 天前的主题，其中的信息可能已经有所发展或是发生改变。
这款产品有一点要注意：
某些客户可能已经有正在用的管理系统软件，我们需要把客户目前再用的管理系统的数据库导入我们的产品的数据中。不同的产品之间，数据库的设计并不完全一致，迁移当然无法做到所有信息都能“无损”迁移，但业务核心该有的关键字段基本都大同小异，关键数据基本都能迁移。
关于数据库设计与数据迁移，有两种架构，选哪个：
-
数据一致性约束放在数据库层面（外键、触发器、存储过程等），当然代码层面也尽量加入用户输入验证与数据一致性检查，只不过以数据库的检查为主。给客户导数据的时候，针对性编写 SQL 文件，直接进行数据库转换。
-
数据一致性约束放在代码层面，数据库完全不使用外键、触发器、存储过程等约束，给客户导数据的时候，不写 SQL，而是直接写代码，使用代码一行一行读取老数据库，然后在代码层面进行数据转换，然后再用代码一行一行插入新数据库。
PS：客户的数据量都不会太大，基本不会涉及分库分表。
 |
1
ZSeptember 2020-08-27 16:01:16 +08:00
对于 ERP 系统，数据库外键，唯一索引应该是要的。
触发器，不太熟悉，不知道触发器的触发机制，如果是跟触发操作在同一个事务中，还是可以用的。就是注意文档，管理要跟上。 存储过程，这个看需求，一般没必要用。 |
 |
2
saulshao 2020-08-27 19:54:09 +08:00
我建议是放数据库里面，还有个问题是不建议有存储过程，太难了。
|
 |
3
einsdisp OP |
|
4
einsdisp OP @ZSeptember @saulshao
多谢回答。一般看来，数据约束（比方说外键）同时在数据库与代码逻辑中都进行约束就行了。 其实我更最想问得是，如果给客户导数据库，一般是用 SQL 语句还是写代码逻辑？ |
 |
5
leeg810312 2020-08-27 21:15:16 +08:00 via Android
数据不多可以用外键，但没有特殊需求，绝对不要用触发器、存储过程等在数据库系统里修改数据的特性，数据修改一定要在代码里实现，这是工程管理的需要。在数据库系统里使用修改数据功能，不仅使得代码调试困难，还造成项目管理的混乱。只有导入初始化数据可以用 sql 脚本，作为系统部署的一部分。
|
 |
6
liprais 2020-08-27 21:18:42 +08:00 via iPhone
想明白一行都不能错的话应该怎么办就行了。
让你在应用里做约束的纯属挖坑 |
 |
7
zjsxwc 2020-08-27 21:23:13 +08:00 via Android
很多老 erp 都是靠各种存储过程支撑的，汗
|
|
8
saulshao 2020-08-28 02:51:22 +08:00
给客户导数据库，我建议是要依靠代码，因为代码的结构组织比 SQL 脚本要有效率得多。
但是从历史上看，大部分的导数据库这种事都是 SQL 脚本完成的。 这么做好处是一次性的开发工作量比较小，坏处是时间长了就搞不清楚哪些地方该改。 |
 |
9
SWALLOWW 2020-08-28 09:31:56 +08:00
正好今天瞄了一眼博客园的推送，正好看到这句话：
是否使用外键约束 [强制] 不得使用外键与级联，一切外键概念必须在应用层解决.-《阿里 Java 规范》 |
 |
10
519718366 2020-08-28 10:33:34 +08:00
这得看你对数据的要求吧。
像我这种经常写 bug 的后端，要去修数据啥的。你给我整一堆外键约束，修数据 /导入数据工作量直接翻翻。 |
 |
11
xiangbohua 2020-08-28 14:15:50 +08:00
我觉得 ERP 这种，如果业务变化很小，并且对数据完整性有非常高的要求，我觉得是好好设计数据库，把约束写在 DB 里面，虽然整体效率可能会下降，但是从源头避免很多脏数据。但是文档非常重要，不然后面没人知道 DB 怎么回事了。
业务多变的话，还是放在代码层面吧。好维护一些。 |
|
12
xiangbohua 2020-08-28 14:17:15 +08:00
@SWALLOWW 阿里的东西也不是放之四海而皆准的，还是要具体问题具体分析
|
Select Language