以下是引用 Harry 于 2009-2-21 17:45:48 发表的文字:
谢老师、江老师：
关于书目的数据结构我有些疑惑、想请教二位老师。
书目应该是非结构化的数据，dp2用SQL Server做数据库，SQL Server是结构化的数据库，书目中字段可重复、子字段也可重复、那不是要设计好多表、想来Marc定义的所有单位都要配一张表，sp2的书目数据库是这样复杂吗？
XML可以表述非结构化的数据，但我一直认为XML用于数据传输而非数据存储，如果用XML存储大量书目数据，那么对其检索、操作效率会不会很低？
DT1000/1500用的数据库是自己开发的，据说是非结构化数据库，最新版的Oracle才有部分非结构化数据处理功能，如此说来二位老师10多年前的工作岂不是很厉害，DT1500我用过，觉得效率挺高的。用dp2导入2000条书目数据大约要半个小时（无法忍受），而DT1500却只用几分钟（甚至更少），如果老数据库效率真的优于SQL Server，那为什么放弃了之前那么好的技术。
可能我的疑惑是源于我的无知，但还是希望二位老师不吝赐教。
这个话题很有意思，它是多年来的一个核心话题，不过，大约我刚出道的时候，也就十多年前，已经就搞清楚了。而最近的这些年，只是在不断实践、优化，理论上没有任何新的突破。
首先关系数据库不是不能描述和存储可以重复的字段。例如你说的用很多的表来描述软件所需的数据，这就是非常非常正规的关系数据库的生存模式。但是，问题长期以来被一些人偷换了：如何仅仅用一张表来描述类似MARC的数据结构？这些人很蠢。就好像我问你：人如何一年之内仅仅吃一顿饭而存活？你肯定会回答说：不对呀，我们平常每天都要吃三顿饭，一年吃1000顿饭呢。
我刚开始编程试图实现图书馆软件的时候，那时候的商用数据库软件还不发达，正好我在大学时候关注过一般数据库的设施例如B+树构造的索引这样的有意思的技术，所以我们那时候就开始自己设计实现数据库。当时dbase已经出现了，也不是完全没有参考的例子。
不管是我们当初自己的数据库，还是现在用商用数据库，数据结构都很直接和简单：用一个表存放MARC数据，当然，MARC数据是不透明的，就像存储图像数据一样。这构成了MARC记录ID和记录体之间的一个二维的简单对照表，这叫做MARC表。然后，建立另外的一些表，把书名、作者等等和刚才这个ID对照起来，形成若干的二维对照表。后面这些叫做KEYS表。KEYS表为了检索的效率，一般需要配备多个，每种独立的检索途径配备一个。
这是正统的关系数据库设计了，教科书里面就是这么举例的，一点都不稀奇。有些人提出一个问题：如何让关系数据库系统自动维护这些表和表之间的关系(比方说，我保存一条MARC数据，关系数据库系统给我自动分拆数据并建立到这些表之中)？这个问题的答案是，不能。必须要开发程序去细心维护，而没有那个商用的关系数据库系统去替你维护。这好比有人去了饭馆，点了菜，问：谁来负责喂我饭？没有人喂你饭，你手脚都不残废，你可以自己吃。
所谓图书馆系统的应用服务器，或者数据库内核，一个重要作用，就是去维护这些表之间的关系。数据库内核概念有了后，就由数据库内核去负责了。刚才说的那些人，可以买我们的产品，那样就不用自己去维护表之间的关系了。不过，至少是要花钱的。
曾经有一个人和我争论，说他纯粹用商用数据库，所以不会出现我们自己开发数据库可能要犯的错误。这个人忘记了，在若干表的设施上面，他还是要不得不开发一些至关重要的数据逻辑处理模块，要加锁，要控制并发，这些事情难度一点也不低，就我开发过数据库的经验来说，和直接开发数据库底层所需要的细心、耐心、控制力是一样的，要求并不减低多少。这个人的逻辑是，作的事情少，犯错误的机会就少。但是他的说法不成立：因为一些容易犯错的事情他丢不掉，必须要做。他不但做了，而且是不情愿地做，犯错误的机率会大增。而且，他在说到软件价格的时候，并没有谦虚地(因为声称自己少作了事情而)降价，而要了高价 -- 比包含自己数据库的产品的价格还要高。
在上面所说的MARC表里面用MARC格式还是XML格式，这个问题不关键。只要能建立MARC数据或者XML数据和KEYS标的关系，也就是说能自如地操纵数据内部结构，能够进行拆分和组装，就可以了。是的，正如你说，它们都是传输格式 -- MARC也是，ISO2709么。但是，没有必要另开发一套专用的存储格式。传输格式完全可以做存储格式。说开一点去，类似UTF-8这样的Unicode传输格式，也被Oracle这样的数据库系统拿来做系统内部存储格式。而MS SQL Server则用UTF-16，更内核一些。
dt1000的数据库和Oracle不能比。dt1000好比一辆汽车，而Oracle好比一台发动机。dt1000自然是包含了自己的发动机，但是在发动机外面附加了另外的庞大逻辑，比如说上面介绍的多表关系。因此直接比较是不公平的。
10多年来，从纯技术的角度，很多环节我们都在下降而不是上升。这和能举的哑铃的重量是一致的。我很希望，如果运气好，市场足够大，我还能操刀作很多很厉害的东西，超过10多年前的水平。
关于速度问题，确实商用数据库并不是最适合某些特定应用的。不过对这一点，我抱淡然的态度，毕竟现在机器硬件在发展，速度问题不是太大。我见过很多人无限崇拜地谈论某些“大”数据库，而对其它事物视而不见，我已经习惯了。大就是慢，就是臃肿，然后就能获得崇拜，这并不是太奇怪的逻辑。
以前的技术并不是完全放弃了。许多事情要看机会。
感谢你的拐着弯的鼓励和夸奖，还有你的独特的眼光和深度。希望以后有机会多多交流。