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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 2649 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

数据库

插入

代码

DBA

9 条回复 • 2017-02-06 14:28:38 +08:00

echo1937

2017-02-06 12:18:56 +08:00

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

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

mhycy

2017-02-06 12:40:51 +08:00 via iPad

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

nybux

2017-02-06 12:42:02 +08:00

insert ignore 可以批量插入不报错

mhycy

2017-02-06 12:43:06 +08:00 via iPad

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

nybux

2017-02-06 12:52:38 +08:00

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

ihuotui

2017-02-06 13:01:35 +08:00 via iPhone

看看云栖的文章吧

CRVV

2017-02-06 14:19:24 +08:00

“需要查重”

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

ryd994

2017-02-06 14:19:36 +08:00

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

CRVV

2017-02-06 14:28:38 +08:00

@CRVV

说错了

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

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