娱乐精神: July, 2006

shuai's profile娱乐精神PhotosBlog

Tools

Help

<< First < Previous Next > Last >>

7/31/2006

X的悲剧和Y的悲剧

最近一口气看完了X的悲剧和Y的悲剧
这是奎恩的推理名篇

这两个小说的共同之处
就是都有一个无法想到的凶手
这个凶手属于不被人关注的角落角色
所以当我看到迷底时被深深震撼了
而这种震撼
是不同于看了行人的馆系列后的被骗之感
是彻底的折服和赞叹

同Y的悲剧相比
X的悲剧更有可读性和故事性
所以非常具有阅读时的吸引感
和可重复阅读性

当小说已经进入尾声
而我仍还在云里雾里
当看雷恩化妆成死者隆斯崔戏剧性的抓到凶手后
我真是被突然出现的凶手震撼
原来是他，那个角落角色
我无论如何无法想到
而雷恩早在隆斯崔被杀后就知道了
我却没有注意到那个细节

Y的悲剧的故事性相比就逊色一些
奎恩故意把让读者引向了错误判断：
凶手误杀错了人、死者儿女们的遗产纠纷
以及那位值得怀疑的身份的家庭教师
在最后，雷恩说凶手已经死了，并揭露迷底时
我被压抑了几章的不爽之感彻底喷发
由此Y的悲剧更像是黄金时代的推理小说
（本来就是黄金时代的推理小说）
----用19章的压抑换来一章的畅快

现在我非常期待奎恩的另一名篇
希腊棺材之谜

10:22 AM | Add a comment | Permalink | Blog it

7/24/2006

Endless Sadness

上次看完NANA

我的心理就出现了问题

今天又听到Endless Story

NANA的插曲

我觉得比中岛的Glamorous Sky有力量多了

青春的残酷

辗转迷茫

温暖而坚定

全部浸入在那曲子的每个音符中

我的心理就又出现了问题

莲

是不是因为追逐而放弃的太多了

if you haven't change your mind
想要你在身边 tonight
早已疲倦了逞强
曾经太过年少 everytime i think about you baby
直到现在才能说出口 i miss you
it is hard to say i'm sorry
不为任何人只为你
唱这首歌
永不完结的story延续在这光芒之中
always 想要告诉你
memories of our time together
不要忘记留在此刻 don't go away
用温暖融化只为了确定
点滴的温柔泛起心中的涟漪
如此的痛苦 i'm missin'you
握紧的手不要放开
如果可以希望再次为你唱这首歌
永不完结的 story 从未消逝的想念
tell me why 请告诉我直到永远

3:36 PM | Add a comment | Permalink | Blog it

7/20/2006

反向键索引

　　Oracle会自动为表的主键列建立索引，这个默认的索引是普通的B-Tree索引。对于主键值是按顺序(递增或递减)加入的情况，默认的B-Tree索引并不理想。这是因为如果索引列的值具有严格顺序时，随着数据行的插入，索引树的层级增长很快。搜索索引发生的I/O读写次数和索引树的层级数成正比，也就是说，一棵具有5个层级的B-Tree索引，在最终读取到索引数据时最多可能发生多达5次I/O操作。因而，减少索引的层级数是索引性能调整的一个重要方法。

　　如果索引列的数据以严格的有序的方式插入，那么B-Tree索引树将变成一棵不对称的"歪树"，而如果索引列的数据以随机值的方式插入，我们将得到一棵趋向对称的索引树

　　既然索引列数据从序列中获取，其有序性无法规避，但在建立索引时，Oracle允许对索引列的值进行反向，即预先对列值进行比特位的反向，如1000,10001,10011,10111,1100经过反向后的值将是0001,1001,1101,0011。显然经过位反向处理的有序数据变得比较随机了，这样所得到的索引树就比较对称，从而提高表的查询性能。

　　但反向键索引也有它局限性：如果在WHERE语句中，需要对索引列的值进行范围性的搜索，如BETWEEN、<、>等，其反向键索引无法使用，此时，Oracle将执行全表扫描；只有对反向键索引列进行 <> 和 = 的比较操作时，其反向键索引才会得到使用。

10:42 AM | Add a comment | Permalink | Blog it

7/14/2006