[讨论]业务主键 Vs. 逻辑主键，到底哪个好？

>>我是十分反对使用主键的
这个有点过了吧？

以前真的要用mysql时，我都先用SQLServer建立demo数据库(check很严格的)，然后用程序控制数据的处理，直到我的程序不出问题才移到mysql

当时我就想，要是数据库能做这些事情多好，就不用我这么累了

这不是过，而是一种教训的积累。当然我的意思不是说你在开发的过程中就不使用主键这些东西了，比如我也会在一个比较自动化的数据库中建立一个数据库，然后导进实际的数据库中。不过我认为程序不应该依赖这些东西。我强烈建议大家多使用视图和虚拟表，这些才是提高效率的正道。而效率也不要过分追求，只要把那些凭径问题解决了就可以，不要为了提高1%的效率就付出99%的努力。而实际上如果你的硬件够好，比如有一个巨大的内存，我就会选择使用中间数据层，这比多数人想象的要容易。

中间数据层的产品有那些？或者说用什么办法实现这个中间数据层呢？

我只知道有个prevayler，在这种模式下，跟本就没有常规数据库的概念，数据库只是用来做内存转储

但是由于数据量大，这个内存转储还是比较费时的，所以我比较担心掉电等意外事件发生时，数据的安全。
或许掉电可以加个UPS解决，但有没有其他隐患呢？

对于效能要求高的应用，唯一的办法就是阵列和内存数据库。依靠数据库自己的效能根本就是做不到的。而且当你要把项目做成产品的时候，直接使用数据库就很麻烦。比如你要新建造一个帐，如果真的需要在数据库中建立新的表格，我想不是好想法。

ozzzzzz，你的意思我明白
说白了，所有的问题都是由于磁介质存储的性能引起的，简单点说就是由I/O来的

想想把那么多的数据在内存和磁盘之间倒腾来倒腾去就郁闷

恩，好象有点离题了

所以啊，要那么一点性能的提高，搞那么大的付出，根本就不核算。要是真的要性能就不依赖数据库。

楼上的话让我感觉是要效能就不要硬盘了，直接用内存算了。问题是内存能大到那样么？
   如果把计算机的中的IO性能比内存的比较泛指到DBMS和内存中缓冲操作的比较似乎有些极端甚至可笑了。很简单地一种方式，你在内存中查对象（根据条件）会比在数据库中快？那么你都可以做一个数据库了，说句老实话，中国还没有这么牛的人啦!

哈哈
当你真的要做高性能的应用的时候直接使用内存几乎是唯一的选择。但是这不是说在内存中建立一个数据库，当然牛人是可以作到的。你要做的就是把数据放在内存中进行直接的处理，而不是利用数据库。数据库的在这种情况下的唯一目的就是存储数据，也就是你会设计一个线程不断的把数据备份到数据库中。你只是利用了数据库的存储功能而没有利用他的其他功能。
所以你去看看电力和电信中的很多系统的数据库都是莫名其妙的东西，这就不奇怪了。

我觉得ozzzzzz兄的话有失偏颇。

>也就是你会设计一个线程不断的把数据备份到数据库中
如果数据用这么一种异步的方式备份到数据库，出现数据写失败怎么办？我可以把log数据用异步方式写数据库，其他数据绝对不敢这么干。

>当你真的要做高性能的应用的时候直接使用内存几乎是唯一的选择
抛开速度不谈，直接使用内存如何保证交易完整性？

当然，我想ozzzzzz兄不可能忽视这些简单问题，肯定有独到的解决办法，但肯定也会花费一定的心思来设计。如果一个系统中，所有的数据和操作都如此“设计”，我想，又陷入了为提高1%的效率就付出99%的努力的境况。因为，再critical的应用系统，绝大多数usecase还是crud，critical case就那么寥寥几个而已。

crud操作最好是使用Hibernate这样的O-R Mapping系统的缓存功能。读操作clone二级缓存中的数据，在一个事务内部保证并发正确；写操作直接写回数据库，并让二级缓存失效。如果采用分布式cache，还可以有效地进行负载均衡。

至于某些场景下的有的关键应用，例如电话机费系统中的记费业务要求响应时间在ms级别，确实应该设计一个内存方案。但这样的方案不会很简单，要充分考虑到具体业务特征，有时甚至不得不牺牲一些正确性。

o6z，你说的不要使用主建，那么一致性可能会损失。。。。人为的控制可能会失误呢？。。。