其实我一点儿都不看好现在的那些把若干关系表生硬地对应到一个程序代码类的O/R Mapping实现。
我说的类是指思考和设计系统数据库结构时的逻辑数据类，对这种数据类的操纵依旧使用传统的数据集或记录集方法。事实上，这是OOSQL使用的方法，不是现在的那些O/R Mapping。

现在流行的那些O/R Mapping技术有一个致命的毛病就是：将数据库结构与代码结构绑死！

而使用传统的数据集或记录集方法，数据库结构的元数据也是程序代码可操纵的一种数据，因此，灵活得多。

在关系数据库的基础上构建出面向对象的数据库的目标是让SQL语句具有面向对象的语义逻辑，虽然依然是用SQL语句操作数据库，这就是OOSQL的目标！

举例说明：
Employee类派生有Manager和Worker类

select * from Employee
将把所有Employee记录查询出来，包括Manager和Worker中的记录。当然，结果集中的列都只是Employee定义的那些列。

select * from Manager
将返回Manager的所有记录，不包括属于Worker的记录。结果集中的列除了Employeed定义的所有列之外，还有Manager的列。

update Employee set EmployeeNo=Value 与 update Manager set EmployeeNo=Value的含义相同，因为EmployeeNo是Employee定义的列。只不过一个基于父类来更新，一个基于子类来更新。

如果“张三”是Manager
delete from Employee where id='张三' 与 delete from Manager where id='张三'也是相同的。前一句删除Employee基表记录的同时，也会保证删除所有继承类基表的相关记录。

而与工资、福利等数据类的关联关系，都会建立在Employee类的层次上，而不需要考虑Manager和Worker的特殊列。当然，如果从Employee派生一个新类Assistant，那么这个新类也将自动适应工资、福利等数据关系，不会对其构成影响。

这些只是OOSQL语义的基本方面。

李战.深圳
2005-2-5