This is all fairly amazing but it gets better. It is often the case an application needs to be changed at some point. For example we may decide we want to change the name of the table from users to people. We also want to add a field called pwd to store the password field (please check the textbox Reserved Words).
所有这些都非常令人惊奇但是它变得更好。许多情况下程序需要在某些地方作出改变。例如我们可能决定需要把表的名字从 users 变成 people。我们可能还需要增加一个域 pwd 来储存密码域（请检查 textbox 的保留字）。
Reserved Words
保留字
The reason we do not call the field password is that this is a reserved word for field names in Interbase. Since we want to be RDBMS independent the MDB manager will either issue a warning or fail if the option fail_on_invalid_names is set to true (which is the default).
我们没有称那个域为 password 的原因是那是 Interbase 中一个域名的保留字。因为我们需要 RDBMS 独立，MDB 管理器要么给出一个警告要么在 fail_on_invalid_names 选项被设置为真的时候（这是缺省值）失败。
In the old days you would now be in a bit of pain to alter all your existing installations to this new schema. But thanks to MDB this can be automated. In listing 5 are the changes we make to our table definition:
在过去的时候，你可能现在正处于把你所有已经有的东西变成这种新的 schema 的痛苦之中。但是由于 MDB 这些工作能够自动完成。在 listing 5 中是我们对我们的表格定义进行的修改：
Listing 5
<table>
<name>people</name>
<was>users</was>
<declaration>
<field>
<name>pwd</name>
<type>text</type>
<length>32</length>
<notnull>1</notnull>
<default></default>
</field>
</declaration>
</table>
Now we want the manager to make the necessary alterations, but before I want to mention a possible pitfall. Since we renamed the table users to people we also have to change all references to the old name like in the sequence we build. There the reference in the on tag needs to be changed to point to the people table. To achieve this we pass the new and the old version of the schema to the manager. This is why we created a .before file when we first called MDB_Manager::updateDatabase(). This ensures that we have an old version of the schema to compare the new version with.
现在我们想要管理器来作出必要的改变，但是在此之前我像提一下可能的陷阱。因为我们把表从 users 更名为 people，我们还需要把所有对原来名字的引用进行更改，比如我们建立的序列。在 on 标签中的索引需要更改为指向 people 表。为了达到这个目的，我们把 shcema 的新旧版本传递给管理器。这酒是为什么我们在第一次调用 MDB_Manager::updateDatabase() 时我们创建一个 .before 文件的原因。这确保了我们有一个旧版本的 shcema 来与新的版本进行比照。
$input_file = 'auth.schema';
$manager->updateDatabase($input_file, $input_file.'.before');
That's all! The users table is now called people and now we also have a pwd field.
所有的就是这样！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);
}