Hibernate 和数据库的外键联系关系
Hibernate 和数据库的外键关联
做项目建数据库时，表与表之间的外键约束太多，导致后来数据库操作时经常出错，于是我们决定把数据中的外键都删除，只在业务逻辑上存在引用关系，在数据库中不存在实体的外键。
可是我们的代码都写到一半了呀，domain包下和javaBeandouy都已经写完，从头再来是不可能的。
于是我就将数据库中的外键都在数据库中删除掉，Hibernate的XML文件和javaBean都没有改变，经过不是很完善的测试，发现是可以的。
我想：数据库中的外键在数据库级别保证数据的完整性和一致性，但是Hibernate也在DAO层保证了数据的关联。所以，我将数据库的外键删除，是不影响Hibernate的，但是这样，我想会造成数据库中存在一定冗余的数据，和无效的数据。但是，对于复杂的业务处理，这点数据库牺牲还是有用的。
这样，所有的业务关联是外键约束，都在java代码里处理了，数据库是没有任何外键约束的。
不知道我这样做有没有问题，或者是违反了什么原则，欢迎拍砖。
是不是一些无用的数据？本来因为外键关联而需要删除掉的，但是因为数据库中没有外键了，所有这些数据就永远留在了数据库中？这些数据就是脏数据？
这样的话，在数据库中不存在外键关联，但是在Hibernate的映射文件中，却存在一对多或多对一的关联关系。那就是说Hibernate的关联关系完全不依赖于数据库的关联关系？
做项目建数据库时，表与表之间的外键约束太多，导致后来数据库操作时经常出错，于是我们决定把数据中的外键都删除，只在业务逻辑上存在引用关系，在数据库中不存在实体的外键。
可是我们的代码都写到一半了呀，domain包下和javaBeandouy都已经写完，从头再来是不可能的。
于是我就将数据库中的外键都在数据库中删除掉，Hibernate的XML文件和javaBean都没有改变，经过不是很完善的测试，发现是可以的。
我想：数据库中的外键在数据库级别保证数据的完整性和一致性，但是Hibernate也在DAO层保证了数据的关联。所以，我将数据库的外键删除，是不影响Hibernate的，但是这样，我想会造成数据库中存在一定冗余的数据，和无效的数据。但是，对于复杂的业务处理，这点数据库牺牲还是有用的。
这样，所有的业务关联是外键约束，都在java代码里处理了，数据库是没有任何外键约束的。
不知道我这样做有没有问题，或者是违反了什么原则，欢迎拍砖。
1 楼
treemap
2011-09-23
没有问题，速度快很多
但是 你必须要明白的是，如果有一些 脏数据 你业务上可以接受
但是 你必须要明白的是，如果有一些 脏数据 你业务上可以接受
2 楼
wangboak
2011-09-23
如何理解这个脏数据啊？
3 楼
wangboak
2011-09-23
treemap 写道
没有问题，速度快很多
但是 你必须要明白的是，如果有一些 脏数据 你业务上可以接受
但是 你必须要明白的是，如果有一些 脏数据 你业务上可以接受
是不是一些无用的数据？本来因为外键关联而需要删除掉的，但是因为数据库中没有外键了，所有这些数据就永远留在了数据库中？这些数据就是脏数据？
4 楼
aa87963014
2011-09-23
删除外键和你说的这些有毛关系？无非没有了数据库的数据校验。
其他的该怎么样就怎么样一点关系都没。业务出现问题出现了错误的外键，这个只能自己通过业务来解决而不是靠数据库帮你验证数据。
其他的该怎么样就怎么样一点关系都没。业务出现问题出现了错误的外键，这个只能自己通过业务来解决而不是靠数据库帮你验证数据。
5 楼
tag13346
2011-09-23
问题在于，日久天长，经过几拨人经手这个系统之后，有多少业务关系可以直接相信，约束是数据安全的最后一道防线，不可轻言放弃
6 楼
wangboak
2011-09-25
aa87963014 写道
删除外键和你说的这些有毛关系？无非没有了数据库的数据校验。
其他的该怎么样就怎么样一点关系都没。业务出现问题出现了错误的外键，这个只能自己通过业务来解决而不是靠数据库帮你验证数据。
其他的该怎么样就怎么样一点关系都没。业务出现问题出现了错误的外键，这个只能自己通过业务来解决而不是靠数据库帮你验证数据。
这样的话，在数据库中不存在外键关联，但是在Hibernate的映射文件中，却存在一对多或多对一的关联关系。那就是说Hibernate的关联关系完全不依赖于数据库的关联关系？