数据库对象关系映射是目前非常火热的数据库访问技术。这又是一门“伟大"的技术，实在有点博大精深了。有兴趣的话，可以自行搜索一下。
Mdtypes只是提供了一个Freebasic版的数据库对象关系映射的基本雏形。但它简单实用，虽然它无法象Entity Frame，或java的ORM那么牛逼哄哄，不过你也不用深陷伟大技术的伟大泥潭的苦恼。
对于经常使用vba的人来说，如果不使用recordset，那么数据库离你大概有十万八千里远，因为如果没有recordset，那么很多人根本不知道如何使用数据库。接下来的数据库对象关系映射，可能是另一个全新的方式（其实是新瓶装旧酒），这个冲击有点大。
        接下来是我的粗浅的认识，可能会有很多错误，甚至理解偏差了，以后随着越来越深入的了解，可以慢慢改正:
 1、数据库对象的映射：
 一个数据库就是一个对象。数据库中有很多表，所有的表构成tables。tables就是一个集合。也有很多存储过程、很多视图、关系，这些都会构成集合。
 一个表本身包含很多行记录。所有的行记录也是一个集合。一行记录（有很多列，每个都有列名），一行记录就构成了一个字典（或map)，
 其中列名就是key，列值就是value，表现为key=value这样的形式。所以一张表，实际上是一个List表+map的复合体（所谓的二维表）。
 一张表中有很多列，所有的列本身也是一个集合，每一个列（字段名）有很多属性，如数据类型等，一个字段名的所有属性描述也构成了一个Map。
 list和map都是对象，所以数据库里的对象，就这样映射到编程语言中的collection和map对象来。
2、数据库数据类型的映射：每一种数据库都有自己的数据类型。而每一种语言也有自己的数据类型，所以需要进行映射。
3、表与表之间关系的映射：这是一个非常蛋疼的话题。因为mdTypes中的持久化，还在发展中，所以这里就不扯。

由于目前mdTypes的持久化，特别是数据库持久化还是基本雏形，所以它的优缺点很明显，而且大部分的缺点是ORM本身就有的
缺点：
1、数据类型的对应：FB的数据类型如何与数据库的数据类型进行快速简便地映射，这本身是一个问题，虽然绝大部分的数据类型可以进行一一对应，但它始终是一个问题
2、colleciton必须有两个构造函数，一个是空的constructor,一个是带有参数的constructor。而FB的构造、解构函数是无法继承。也就是说这代码只能不厌其烦
地进行复制。同样的两个operator  cast()和=也是无法避免。
3、目前还无法避免必须对数据库表设计的深入了解。虽然对于小项目，这没什么，但始终是一个大问题。
4、每次查询都得定义一次map的结构，并进行数据类型转换，这个工作量不小。（或许会有更简便的方法？）