The XML schema management is another important piece in the database abstraction concept that MDB provides. It allows us to keep our schema definition independent of a specific RDBMS. But using this format also ensures that the correct native data types are used so that MDB can correctly map its native data types. Finally, since the format is based on XML it is much easier to write tools that generate or read XML schema files.
XML schema 管理是 MDB 提供的数据库抽象概念的另外一个非常重要的部分。它使得我们保持我们的 schema 定义与特定的 RDBMS 无关。但是使用这个格式还确保了使用正确的原生数据类型因而 MDB 能够正确地映射它的原生数据类型。最后，因为数据是基于 XML 的，编写产生或者读取 XML schema 文件的工具要容易一些。
Sounds great but my application already uses ...
听起来不错但是我的应用程序已经使用了……
Most readers probably find themselves in a position where they already have a number of applications that run on some other database abstraction layer. Due to MDB's heritage most PEAR DB users should find that MDB feels very similar, since the API of MDB is based on that of PEAR DB. Metabase users should find that all their favourite functions have their counterpart in MDB. The XML schema format is exactly the same as in Metabase. A complete guide to porting your existing applications to MDB is beyond the scope of this article, instead I will use this space to give some tips. If you have any specific questions feel free to email me.
大部分读者可能发现它们处于这样的境地——他们已经有了大量运行于其他数据库抽象层的程序。由于 MDB 的出身，大部分 PEAR DB 的用户应当发现 MDB 感觉上非常类似，因为 MDB 的 API 是基于 PEAR DB 的。Metabase 用户应当发现他们所有偏爱的功能都在 MDB 中有对应的东西。XML schema 格式和 Metabase 中的是一摸一样的。一个完全的指导来引导你把已经写好的程序移植到 MDB 中超出了本文的范围，但是我将利用这个机会给一些提示。如果你有任何具体的问题，放心的发信来询问我。
To port your PEAR DB application to MDB the best place to start is the PEAR wrapper. For one you can run your application using the PEAR wrapper. The wrapper of course does add a little bit of overhead so you will probably want to port to the native interface at some point. The first step then should be listing all PEAR DB methods that your application currently uses. Then look at the wrapper for any differences in the API. There are two key differences you will notice: result sets are not objects anymore and all of the querying methods allow you to pass the data types of the result set which will result in slight changes in the parameter order. The first difference means that instead of calling the fetch method on the result object:
为了把你的 PEAR DB 程序移植到 MDB，最好的起点是 PEAR wrapper。你能使用 PEAR wrapper 来运行你的程序。wrapper 当然增加了一些额外负担，因而你可能有些想要移植到原生的接口。那么第一步是列出所有你程序当前使用的 PEAR DB 函数。然后看看 wrapper 从中找出任何 API 上的区别。有两个你要注意的关键区别：结果集不再是对象而且所有的允许你传递结果集的数据类型的查询方法将导致参数顺序上的少许改变。第一个区别意味着不能再结果对象上调用获取函数。
$result = $db->query($sql);
$row = $result->fetchRow();
You will now have to call the MDB object for fetching:
你现在必须调用 MDB 对象来进行获取：
$result = $mdb->query($sql);
$row = $mdb->fetchRow($result);
The second difference is quite easily fixed by looking at the wrapper. As you can see in the wrapper you may simply pass NULL where MDB would otherwise expect data types in the result set. Now, your application should work with MDB. Of course, you are now not really taking advantage of the advanced features of MDB. This most likely will require some changes to your current database schema. The manager can attempt to reverse engineer an XML schema file from an existing database. A very simple front end can be found in the MDB package: the reverse_engineer_xml_schema.php script. Most likely you will need to manually fix the resulting XML schema file, but it will give you a nice starting point.
第二个区别通过观察 wrapper 可以轻易的被解决。如你再 wrapper 中能看到的，你可以再 MDB 期望得到结果集的数据类型的地方简单地传递 NULL。现在，你地程序应当能够使用 MDB。当然，你现在没有真正得到了 MDB 地高级特性优点的益处。这最有可能的是需要对你当前的数据库 schema 进行一些改动。管理器能够尝试反向地从已经存在的数据库中获取 XML schema 文件。一个非常简单的前端可以在 MDB 包中找到：reverse_engineer_xml_schema.php 脚本。极有可能你将需要手动修正产生的 XML schema 恩见，但是它将给你一个很好的开始。