关于数据库的存储过程 or 数据最佳实践？

[twogoods]

主要还是 mysql ，公司 DBA 说把数据库用得最简单，存储过程也不让用，一定要放到代码逻辑里去。批量插入的每一条数据还需要查重的场景，代码处理有什么优雅一些的做法吗？建唯一索引，重复的就报错无法插入，这样的错误如果频繁的报会对数据库有影响吗(因为写程序毕竟是不想看到错误啊异常啥的)？

[echo1937]

你家 DBA 说的基本没错，现在的业务架构都是尽量不把逻辑处理放到 DB 侧，外键、存储过程等更是能不用坚决不用。

这样做能够提高数据库性能，增加业务系统整体的灵活性和可扩展性。

[mhycy]

@echo1937 但是代价是必须程序侧考虑并发与一致性问题

[nybux]

insert ignore 可以批量插入不报错

[mhycy]

@nybux 显然关注点不在这，在如何保证程序可靠性上面

[nybux]

题主给出的信息量不够，不管用不用存储过程，可靠性都不是问题。
存储过程主要是为了提高复杂业务逻辑的性能，还有就是能屏蔽数据库结构设计的底层细节

[ihuotui]

看看云栖的文章吧

[CRVV]

“需要查重”

我怎么觉得，在通常情况下，使用 UNIQUE INDEX 是这件事的唯一方案

[ryd994]

就算业务逻辑再复杂再消耗大，都可以横向扩展解决。而数据库是很难横向扩展的。所以规模大了以后，瓶颈都是压在数据库上。本来压力很大的数据库，你还想多分工作给它？

[CRVV]

@CRVV

说错了

刚试了一下, 在 PostgreSQL 上, 用 SERIALIZABLE 的事务，先 SELECT * FROM table WHERE v = value, 如果没有重复的再插入, 也可以保证唯一
不一定非要用 UNIQUE INDEX

当然, 我猜 SERIALIZABLE 事务的开销比 UNIQUE INDEX 大