您现在的位置： 
所有的就是这样！users 表现在称为 people 并且我们也有了一个 pwd 域。
I now want to look at one last feature of the XML schema format. This feature is especially important if you want to programmatically use the manager. Imagine that you have several customers that have the same authentication application running on your database server. Every customer has a database running on this server with the same schema but one minor difference: the name of the database. While it may be feasible to keep separate schema files for each client because the update cycles will not be the same this is not the case for our sample authentication application. Here all clients will be updated at the same time. The XML schema format allows us to use the variable tag for this.
我现在要看看 XML schema 格式的最后一个特性。如果你想要编程性的使用管理器，这个特性尤其重要。假设你有好几个有相同验证程序运行在你的数据库服务器的客户。 每个客户有一个服务器运行在这个服务器有相同的 schema 只有微小的区别：数据库的名字。可能为每个客户单独保存 schema 文件是可行的因为更新周期可能不是一样的，这不是我们例子验证程序的情况。这儿所有的客户同时更新。XML schema 文件允许我们为此可以使用变量。
<?xml version="1.0" encoding="ISO-8859-1" ?>
<database>
<name><variable>name</variable></name>
</database>
We can now set the variable name at run time to whatever we may need.
我们现在在运行时设置变量为任意我们需要的东西。
foreach($clients as $name) {
$variables = array('name' => $name)
$manager->updateDatabase($input_file, $input_file.'.before', $variables);
}
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 恩见，但是它将给你一个很好的开始。
If you want to port your existing application from Metabase to MDB you will have to change all of your function calls. Looking at the Metabase wrapper it will become quite obvious what changes need to be made. If you know regular expressions well you might even be able to get most of the work done with a few such replacements. Anyways, you should be up and running your old beloved advanced abstraction features but now using MDB in no time. What you will probably notice is that the method names are much shorter now. If you do some benchmarking you will also see a nice performance increase.
如果你想要把你已经存在的程序从 Metabase 移植到 MDB 你将必须改动所有的函数调用。查看 Metabase wrapper 需要改动什么将变得非常明显。如果你知道正则表达式你可能能够完成大部分这样的替换工作。无论如何，你应当向前并且运行你原来喜爱的高级抽象特性但是现在用的是 MDB。你可能注意得到的是函数名变得更加简短了。如果你作一些性能测试，你也将看到可观的性能改善。
So what does the future look like for MDB?
那么 MDB 将来会是什么样子呢？
At the time this article publishes MDB will have moved on from the original 1.0 release. Next to the original MySQL and PostGreSQL drivers MDB will also have an ODBC driver and possibly even more drivers. This is one key area that is focused on during the development of MDB. Once MDB has caught up with PEAR DB in terms of drivers it is likely to become the standard database abstraction layer in the PEAR framework.
本文发表时 MDB 可能已经不再是原来的 1.0 release 了。在原来的 MySQL 和 PostGreSQL 驱动之后，MDB还将有一个 ODBC 驱动以及可能的更多的驱动。这是 MDB 开发过程中关注的关键区域之一。一旦 MDB 在驱动方面跟上了 PEAR DB，它很有可能成为 PEAR 框架中标准的数据库抽象层。
But there is another key area of development: the MDB_frontend project. The MDB_frontend will be a phpMyAdmin like webfrontend based on MDB and the MDB manager. With this tool you will be able to browse databases stored on any RDBMS that MDB supports. The MDB_frontend will show both the native and the MDB data types. Emulated features such as sequences in MySQL will be hidden. The user will simply see a list of sequences and not a table storing the value of the sequence which is how sequences are emulated in MySQL. Furthermore the MDB_frontend will assist in porting existing databases to match the native data types that MDB expects to be used. It will also help in creating and updating XML schema files. Some initial work has been completed but much more work is needed before a public release can be expected.
但是还有另外一个开发中的关键领域：MDB_frontend 工程。MDB_frontend将成为基于 MDB 和 MDB 管理器的 phpMyadmin。有了这个工具，你将能够浏览储存在 MDB 支持的 RDBMS 中的数据库。MDB_frontend 将同时显示原生和 MDB 数据类型。模拟的特性比如 MySQL 中的序列将被隐藏。用户将仅仅看到一个序列列表而不是一个储存序列指的表，而在 MySQL 中这就是序列是如何被模拟的。而且 MDB_frontend 将帮助移植已经存在的数据库来符合 MDB 预期使用的原生数据类型。它还将帮助创建和更新 XML schema 文件。一些初期的工作已经完成了但是很多工作需要在公开发布之前被添加。
While drivers and the MDB_frontend are the focus of all development currently, there are other things that MDB users may need: Like the integration of bulk fetching of LOB fields, others may need foreign and primary key support. As always in opensource things will go faster if you participate in testing and implementation. But I am also thankful for any other feedback like feature requests.
驱动和 MDB_frontend 是当前开发的所有焦点，在 MDB 中还有许多用户可能需要的：像 bulk 获取 LOB 域的集成，其他人可能需要外部和主键支持。如一直以来的那样如果你参与测试和实现，开源的东西将加快很多。但是我也很感谢像特性需求合阳的反馈。
Some final thoughts
一些文后的思考
After months of hard work MDB is gaining acceptance among the current PEAR DB and Metabase users. I also hope that people that so far have not been convinced by other database abstraction layers realize the benefits that MDB holds for them. Of course, there are still a lot of applications that need to be tailored specifically to one RDBMS where a tool like MDB just ads unnecessary overhead and restrictions. Overall I am very pleased that we made the decision in my company to lead the MDB development. In the beginning, we were all a bit worried that by attempting to please both the PEAR DB and Metabase users the result would end up pleasing neither side. Another source of concern was if the PHP community would assist in the development or not. I am very happy that the PHP community came through and helped in writing drivers and helping on the core of MDB as well. Therefore we consider this project to be a huge success. We are sure that together MDB will be improved even further. And we are happy to have helped making PHP even better.
在数月的艰辛工作之后，MDB 正在当前的 PEAR DB 和 Metabase 用户中获得认可。我还希望当前还没有被其他数据库抽象层说服的用户意识到 MDB 给他们的好处。当然，还是有许多程序需要对 RDBMS 进行特殊剪裁，对于这种情况像 MDB 这样的工具仅仅是增加了不必要的额外负担和限制。总的来说，我非常高兴我们在我们的公司中作出领导 MDB 开发的决定。在起初，我对尝试同时取悦 PEAR DB 和 Metabase 的用户但是结果可能到处不讨好多少有些担心。另外一个关心的来源是 PHP 社区是否将帮助其开发。我非常高兴 PHP 社区来了并且帮助撰写驱动以及 MDB 的核心。因而我们认为这个项目是一个极大的成功。我们还一并相信 MDB 将得到更大的改进。而且我们对帮助 PHP 变得更好感到高兴。
Lukas Smith is the lead author of PEAR MDB. He actively contributes to various PHP opensource projects
