希望大神们给分析分析。
我个人感觉CRUD可以是CR(DC)D, 而且有些时候性能会更好。
最近我们有一个表，ScanDensity只有16.6%，问题相当严重。
只要有操作，就一定会产生碎片。数据库的处理思维和程序思维不太一样。
我在想你的CRUD是不是说的程序，CR(DC)D说的数据库。
很多业务系统是不能执行delete 的，只有到一定阶段进行审计以后，把逻辑删除的数据行搬走或者删除。我表示看不懂
这个和性能有什么关系呢
受益颇多啊~
文件系统存储没用过，数据库更倾向crud，来学习了。你这个命题太广，我觉得倒也不是说具体问题具体分析，而是具体角度具体观点。
V一下，"csdn 300万.zip"含金量更高了。
且不说技术上的实现。（update or insert and delete 都将造成 索引的重建。这个的性能谁好，可以去查查资料）
我就说说业务上的实现，肯定是不取的。
为什么？
比如说常见的 某个物品的基础数据。很多订单中都引用了此物品的ID。
现在本来是要更新它，你变成删除，再添加，想想，问题来了吧，新的ID。如何将新的ID应用到订单中。
这岂不是一个大问题。
就为了那么一点点都还没有证实是优化性能的结论。却带来的更多的麻烦，值么？
自己的一些看法
数据库中，索引是B树，更新的代价是查找一次，删除和插入会引起索引的重构，当你数据库索引字段比较多的时候，就不要为了省自己编写代码的工作量去降低工作性能，当然，非数据库的就有时不如删除插入了，不过要清楚这两者行为大多数情况下会有差异，尤其是牵扯到索引或者数据重复唯一性等如果你承认这不是在讨论设计，而纯粹是一个技术问题，那么这是可以的。但是假设你妄图以此来说服真正的负责业务逻辑的项目开发管理人员，这往往是一厢情愿的。
一旦需要从设计上考虑问题，那么所有的什么“技术”就是神马浮云、都可以重新编写代码。
一旦需要从设计上清楚地去定义“更新、删除”的不同业务逻辑含义，并且围绕着不同业务逻辑去编写业务触发机制，那么很多事情该不该一厢情愿地胡乱联系，这才清楚。每一种不同的操作都有不同的流程，就好像“你换一个女朋友”不等于“把前一个女朋友穿越回到从前不认识你的那个时期”一样，在实际设计上人家都会对每一个具体的动作定义不同的业务逻辑。
只有某些不管不顾的程序员才会随便因为一点技术理由来一厢情愿地随便修改业务逻辑。当然啦。如果你使用了不定长的记录，而新记录比原来的长，为了节约存储，系统使用可变存储空间保存记录，显然直接更新（将记录后面的数据向后移动，腾出空间再插入）的效率要比删掉重建的差很多。从数据库系统的设计看，它当然会采用符合它设计的有利于性能的方法，难道还需要等你越俎代庖帮它优化？我猜想,楼主是不想去编写update的代码,才会想到评估这种方案
如果真是这样,这个只需要设计手段就能解决,
最简单的,现成的手段就是利用ado.net,
insert,update,delete和一些简单的查询都不需编写代码反过来说，如果你确实是“先删除、再新增”地去操作，那么就承认自己是“先删除、再新增”就好了。完全没有必要说“你们熟悉的Update概念都被我颠覆了”。
------解决方案--------------------------------------------------------对于msSqlserver,微软就是采用Delete&Insert处理Update的,
但是,这是系统事务,
如果楼主想自己这样做,你能保证自定义事务的可靠性么?
还有一个最要命的问题,就是并发
CR(DC)D
似乎是把更新换成先删除再插入?
性能差了好多个级别啊