CR(DC)D
似乎是把更新换成先删除再插入?
性能差了好多个级别啊

我猜想,楼主是不想去编写update的代码,才会想到评估这种方案

当然啦。如果你使用了不定长的记录，而新记录比原来的长，为了节约存储，系统使用可变存储空间保存记录，显然直接更新（将记录后面的数据向后移动，腾出空间再插入）的效率要比删掉重建的差很多。从数据库系统的设计看，它当然会采用符合它设计的有利于性能的方法，难道还需要等你越俎代庖帮它优化？

V一下，"csdn 300万.zip"含金量更高了。

自己的一些看法
数据库中，索引是B树，更新的代价是查找一次，删除和插入会引起索引的重构，当你数据库索引字段比较多的时候，就不要为了省自己编写代码的工作量去降低工作性能，当然，非数据库的就有时不如删除插入了，不过要清楚这两者行为大多数情况下会有差异，尤其是牵扯到索引或者数据重复唯一性等

最近我们有一个表，ScanDensity只有16.6%，问题相当严重。
只要有操作，就一定会产生碎片。数据库的处理思维和程序思维不太一样。
我在想你的CRUD是不是说的程序，CR(DC)D说的数据库。

最近我们有一个表，ScanDensity只有16.6%，问题相当严重。
只要有操作，就一定会产生碎片。数据库的处理思维和程序思维不太一样。
我在想你的CRUD是不是说的程序，CR(DC)D说的数据库。

引用 15 楼 fengyarongaa 的回复:最近我们有一个表，ScanDensity只有16.6%，问题相当严重。
只要有操作，就一定会产生碎片。数据库的处理思维和程序思维不太一样。
我在想你的CRUD是不是说的程序，CR(DC)D说的数据库。
是的。 确实是这个样子的。
不管那个Update持久层怎么写，表现在逻辑上肯定也都是Update。 
CR(DC……

你这个命题太广，我觉得倒也不是说具体问题具体分析，而是具体角度具体观点。

希望大神们给分析分析。

我个人感觉CRUD可以是CR(DC)D, 而且有些时候性能会更好。

很多业务系统是不能执行delete 的，只有到一定阶段进行审计以后，把逻辑删除的数据行搬走或者删除。

引用 楼主 sunzongbao2007 的回复:希望大神们给分析分析。

我个人感觉CRUD可以是CR(DC)D, 而且有些时候性能会更好。

且不说技术上的实现。（update or insert and delete 都将造成 索引的重建。这个的性能谁好，可以去查查资料）

我就说说业务上的实现，肯定是不取的。
为什么？
比如说常见的 某个物品的基础……

具体角度具体观点。

引用 楼主 sunzongbao2007 的回复:希望大神们给分析分析。

我个人感觉CRUD可以是CR(DC)D, 而且有些时候性能会更好。

且不说技术上的实现。（update or insert and delete 都将造成 索引的重建。这个的性能谁好，可以去查查资料）

我就说说业务上的实现，肯定是不取的。
为什么？
比如说常见的 某个物品的基础……

具体角度具体观点。