不使用外键数据完整性到底如何保证

Question

问题:
不使用外键数据完整性到底如何保证, 或者说程序层面如何保证数据完整性?

已知的方法:

一. 使用数据库悲观锁,对相关数据进行锁定, 如:select ... for update形式

缺点: 操作不当, 可能造成死锁

二. 使用分布式锁, 如: redis

缺点: 主要在于redis锁的不可靠(如:需要设置过期时间,防止死锁. 但过期时间太短,可能造成锁失效. 主从环境可能造成多个请求同时获取到同一把锁)

实际情况中主要是这种情况想不通

模拟环境:

存在表:
角色表: id为整型主键, 且自增
菜单表: id为整型主键, 且自增
角色菜单表: id为整型主键, role_id为与角色表id关联的建(不建立外键关系), menu_id为与菜单表id关联的建(不建立外键关系)

当向角色菜单表插入数据时, 如何确保role_id,menu_id在对应的表都是存在的.

当然, 我知道, 可以在插入之前使用role_id,menu_id在对应的表查一下, 确认是否存在.但我看了很多系统都没有做这方面的检查.

想不通的地方

1. 是这种情况下, 根本不需要考虑数据完整性问题吗?(或者说即使存在数据不完整的情况, 也可以不在意)?

问题点: 因为id是自增, 如果, 被恶意用户, 往角色菜单表对特定角色插入了几个未来的menu_id,那么就有可能,造成当那几个未来的menu_id被创建出来之后, 那个特定角色就自动获取到了该菜单的权限, 而管理员可能根本不知道.

不知道我这种表述你们是否明白?

Answer 1

绝大多数情况下，数据稍微有点错误都是可以接受的，一般来说，错误在1%之内都可以接受，基本上不需要锁数据。当然，也有需要严格事务隔离，绝对不能出错的数据，比如财务的数据，这时候最好用数据库的锁或者事务隔离机制去保证。

Answer 2

凡是一致性问题都应根据业务场景来，看你的业务场景是需要强一致性还是最终一致性，8成的业务是可以接受最终一致性的，涉及到钱的就需要强一致性了，当然，实现强一致性就必然会在一定程度上牺牲吞吐量，所以才要根据业务场景来。

ps：你问的我没看懂，我就简单说下一致性的问题……