并非万能的XML
左直拳
XML是个炙手可热的东西，出来很多年了，好象还听说将取代HTML（不过直到今天HTML1.1还健在，其实我认为两者很大程度上并无可比性）。有一次我去面试，人家问我熟不熟悉XML，答曰不会，结果被“人来落闸放狗”地赶了出来。
现在我已经在一些地方应用到了XML。众所周知，。NET与XML绑得很紧，比如DataSet，比如WEB SERVICE传递的参数以及返回值。做产品介绍类的网站，如果将产品信息存放在XML文件里，因为不必去查询数据库，速度会很快，同时结合XSL，呈现的样式又很灵活，修改也非常方便。另外，我还很喜欢将程序的配置文件写成XML形式，用DataSet可以不写什么代码就能够读出来。
不过看起来，XML比较适合少量的数据，记录一多，弊端就出来了。之前做的一个网站，需要不定期上传本地系统的数据。采取的办法是本地系统（PB作品）先将数据导出为XML，然后上传此XML文件到网站，读取分析，保存到网站数据库。
刚开始还未发觉有什么不妥，只是速度慢了一点。直到有一天，客户上传了一个包含3万多条记录的文件，不管重复了多少遍，网页最终还是显示“连接已超时”。其实在网页的服务器端代码里，我已经标上
Server.ScriptTimeout = 900;
IIS也已经将网站的连接超时值由120秒设成900秒。
那个文件并不大，只有2M多一点，不过由于记录短，所以数目比较多，有3万多条。我调试了一下，发觉时间既不是耗在上传上，也不是在更新数据库上，而是在文件读取上。
这说明，XML的读取效率不高，也许是因为它采取了明文存取的原因吧。
后来的解决办法是抛弃XML，改用DBF格式，将数据导成DBF文件，然后上传，读取，保存，文件也小，整个过程只须几十秒。
读入DBF主要是靠SQL SERVER。语句如下：
string sql = "INSERT INTO " + table_name + " SELECT * FROM OPENROWSET('MICROSOFT.JET.OLEDB.4.0','dBase IV;HDR=NO;IMEX=2;DATABASE=" + DBF文件所在目录 + "','SELECT * FROM [" + DBF文件名 + "]')";
要执行这条语句，数据库的登录名要具有System.Administrators服务器角色。