coComment reborn

6 Comments

很早以前，大概是在2006年2月份的时候，coComment这个比较有趣的服务出现了，记录你在各个网站的留言，在coComment站点统一进行管理。

在2006年的时候我在kDoliphin的站上说过：

始终觉得操作步骤有些繁琐，因为添加了一道点击 coComment标签的手续，也就是要求改变人们的操作习惯，这个恐怕是coComment发展的一大阻碍，如果可以做到对用户透明就狂放了。
并且还要有等待连接coComment站点的时间，有时候网络问题会导致等待很久。

之后，就没再继续关注这个新生的服务，果然，coComment也没有再有什么大的动静。

今天，忽然在gmail的信箱里面收到coComment的来信，说是升级了2.0版。

1. 推出了Firefox的插件，不再需要像以前那样点击coComment标签，这是必须的。
2. 更加Web2.0，推出了Community，包括创建兴趣组，创建好友，分享Comment等等。
3. 添加了Tag功能。

在安装完了coComment插件以后，任何一个网站留言输入框的下面都会出现一个小横条。

mwsnap237.jpg

默认状态不需要去管它，只要像平常一样写留言，然后Commit就可以。

之后，就可以登陆coComment网站，在自己的用户下统一管理自己的所有留言了。

也许，现在coComment可以有更大的发展了吧。
欢迎大家使用本文测试coComment。

Oracle 11g new feature – Virtual Column

3 Comments

在之前的一篇 – Oracle 11g New Feature – Partition 文章中曾经提到虚拟列的概念，但是当时自己也有些疑问，今天在Oracle 11.1.0.6 上简单测试了一下。

CREATE TABLE tb_v
(col_1 number(6) not null,
col_2 number not null,
col_v as (col_1+col_2));

— 由于虚拟列的存在，所以即使指定了全部的实际列的值也会报值不足的错误
SQL> insert into tb_v values(1,2);

insert into tb_v values(1,2)

ORA-00947: not enough values

— 虚拟列中不允许显示插入值
SQL> insert into tb_v values(1,2,4);

insert into tb_v values(1,2,4)

ORA-54013: INSERT operation disallowed on virtual columns

–必须明确指定列名，才能正常插入数据
SQL> insert into tb_v(col_1,col_2) values(1,2);

1 row inserted

–检索表，已经自动计算虚拟列的值
SQL> select * from tb_v;

COL_1 COL_2 COL_V
——- ———- ———-
1 2 3

–选取该行ROWID
SQL> select rowid from tb_v;

ROWID
——————
AAAEdcAAEAAAC3/AAA

— 获得该行数据存放得到数据文件号
SQL> select dbms_rowid.rowid_relative_fno(row_id => ‘AAAEdcAAEAAAC3/AAA’) from dual;

DBMS_ROWID.ROWID_RELATIVE_FNO(
——————————
4

–获得该行数据存放的block号
SQL> select dbms_rowid.rowid_block_number(row_id => ‘AAAEdcAAEAAAC3/AAA’) from dual;

DBMS_ROWID.ROWID_BLOCK_NUMBER(
——————————
11775

— Dump这个数据块
SQL> alter system dump datafile 4 block 11775;

System altered

下面是dump内容的节选，可以看到确实只保存了两个字段，也就是虚拟列的值并没有存储在block中

block_row_dump:
tab 0, row 0, @0x1f8f
tl: 9 fb: –H-FL– lb: 0x1 cc: 2
col 0: [ 2] c1 02
col 1: [ 2] c1 03
end_of_block_dump

继续在虚拟列上创建索引，然后再看看索引的存储是否有不一样的地方。

SQL> create index idx_v on tb_v (col_v);

Index created

— 获得索引存储的文件号和block号
SQL> exec show_space(p_segname_a => ‘idx_v’,p_type_a => ‘INDEX’);

Total Blocks……………………….8
Total Bytes………………………..65536
Unused Blocks………………………4
Unused Bytes……………………….32768
Last Used Ext FileId………………..4
Last Used Ext BlockId……………….11777
Last Used Blocks……………………4
Last Used BlockId…………………..11780
FIRST LEVEL BITMAP BLOCK…………….11777
SECOND LEVEL BITMAP BLOCK……………11778
PAGETABLE SEGMENT HEADER…………….11779
FIRST Trans Data BLOCK………………11780
Dump SQL: alter system dump datafile 4 block 11780;

Dump 索引块，下面是Dump内容的节选，c1 04就是3，因此可见在创建索引的时候，Oracle会先去计算虚拟列的值，然后再根据结果创建索引。
row#0[8024] flag: ——, lock: 0, len=12
col 0; len 2; (2): c1 04
col 1; len 6; (6): 01 00 2d ff 00 00
—– end of leaf block dump —–

实际上基于虚拟列的索引就是一个函数索引，可以从DBA_INDEXES.FUNCIDX_STATUS=’ENABLED’这个条件得到验证。

其它的一些测试可以参看Oracle11g新特性：虚拟列virtual column from Ningoo。

下一篇计划测试虚拟列的性能。