Thought Persistence

减少相关日志显示为5条

修改计算公式为：
所以为了更好地相关性显示，可以：
细化分类，这样对用户阅读也有帮助
尽可能地添加有关的TAG，如果一个TAG也没有，那么是没有相关日志显示的

比如说老梦的硬盘录像机，就可以做为一个分类而存在

采用uniqueidentifier (以下用guid代替)做主键有它的不可替代的优势，因其不重复性，可以用于数据合并、分布、交换等各种场合，可以由客户端生成并存储，避免了像identity一样需要多一次读取操作，但是它也有着固有的缺点，如不易读，存储和性能都不如int型。

既然我们用了guid做主键，而且我们一般情况下主键即聚集索引，如果这样的话，那么问题就来了：

1、guid的分散性会导致新增记录时可能产生大量的split page操作，这种操作对插入时的性能影响是巨大的，我们希望插入和更新操作不会随着数据量的增加而线性增加。

2、分散性同样导致读取批量记录集时可能会产生多次I/O读操作，因为需要的数据可能分散在各个page中，这种情况在list查询以及master-detail操作中经常会遇到，和上面一样，我们不希望读取操作的cost随时间而大大增长。

而我们的要求是：
1、写条件 -- 新插入的数据不会去影响以前page的存储
2、读条件 -- 读取批量数据时然后在最靠近的pages中获取

那么如果我们要做到这样该怎么办呢?

举个例子吧，有Order和OrderLine两个表(我不喜欢用复数命名，因为如果要mapping到class的话，还是单数最贴切):
一、对于Order表，首先我们将聚集索引从OrderID主键上移出，放到CreatedDate，这样最能满足写条件了，但是读条件不一定满足，因为可能我现在做了一票orderdate为上上个月的单据，于是我们把聚集索引放到OrderDate上去，因为一般来说，批量取的都是OrderDate在一个日期范围的数据。

那么这种方案是不是最好的呢？未必，因为如果OrderNo是根据OrderDate生成的而且也呈有序状态，那么把聚集索引放在它上面，会对大量的单数据读取(OrderNo = 'xxxx')节省一个bookmark lookup的时间，而且同样可以满足条件1和2。
...

阅读全文...