这两天试着把一个论坛的数据导入到我自己做的论坛，
两个论坛架构完全不一样，导也不是好导的，
其中最大的区别是两点：

一、我没有ntext类型的数据，
帖子内容不存在数据库里，而存在文件文件中，
数据库里只存一个类似于“2006/11/26/12345678”的文本，
要生成htm文件的时候，
在这个文件前面加上一个特定的文件夹，后面加上“.txt”即可读取所有内容。

二、我用真正的datetime类型存放时间，
不像那个论坛，居然用一个十四位的整数来存放时间，


于是，导数据就包含了这样两个步骤：
一、根据他原来的十四位整数产生我的时间，
二、将ntext内容存入文件文件，另外将文件名存入数据库，删除ntext列。

第一个步骤是这样的：
While Not c.Eof'注：c是一个数据库对像
nTime = c.Fields("nTime")'读出他的十四位整数
sTime = CStr(nTime)'转为字符串
'变成yyyy-mm-dd hh:mm:ss格式
sTime1 = Left(sTime, 4) & "-" & Mid(sTime, 5, 2) & .....
c.Fields("doctime") = sTime1'写入
Wend


第二个步步骤是这样的：
早在第一步骤时，就先用我自己的函数将时间转成“yyyy/mm/dd/hhmmssuuuu”字符串
并且已经存入表中，
现在剩下的就是写文件了，
这也有我自己的函数：
b.SaveStringToFile(sContent, sFileName)
同样也要放在While...Wend循环中循环几十万次。

面对着几十万条记录，
我原以为这两个步骤一定是个漫长漫长的过程，
谁知道也挺快，几个小时就OK了。

今天，面对一个比这些都简单的工作，却发现耗时间比这还长，
起因是我误删了一个数据列，今天要把它恢复过来，
从某处恢复了一个表来，然后两个表之间同步一个列的数据：

虽然不要写文本文件，也不要进行数值到字符串再到时间的转换，
只是从int到int的复制，但是耗的时间不比昨天少，
想来想去终于明白了：
昨天的工作虽然在几十万条数据之间循环，必竞循环就只有循环，
循环里面对数据库的操作不多，
而这次循环里面还要UPDATE，而这个UPDATE又包含了SELECT，
是这样的：
UPDATE bbsdoc SET rootid =
(SELECT rootid FROM nn WHERE id=值)
WHERE id = 值

把这样一个带SELECT的UPDATE运行几十万次，
比把几十万个十四位整数转为字符串再转为时间要慢，
比把几十万个ntext存到文本文件中要慢。
我靠。