您现在的位置： 
我们现在将从头编写一个 XML schema 文件。首先，我们必须定义一个 XML 文档。数据库定义是包含在一个 database 标签之中的。数据库的名字是使用 name 标签定义的。create 标签告诉管理器数据库是否需要在它不存在的时候被创建。如果你把你的 schema 文件分割成好几个文件你你首先提交给管理器的那个文件中把 create 设置为 1。
<?xml version="1.0" encoding="ISO-8859-1" ?>
<database>
<name>auth</name>
<create>1</create>
</database>
As you may have guessed from the database name auth the purpose of this database is to store user data for a simple authentication application. Listing 2 defines a table in which we can store the user data.
可能你已经从数据库名 auth 猜出了这个数据库的目的是用于储存简单的验证程序的用户数据。Listing 2 定义了在其中我们能储存用户数据的表。
Listing 2
<table>
<name>users</name>
<declaration>
<field>
<name>user_id</name>
<type>integer</type>
<notnull>1</notnull>
<unsigned>1</unsigned>
<default>0</default>
</field>
<field>
<name>handle</name>
<type>text</type>
<length>20</length>
<notnull>1</notnull>
<default></default>
</field>
<field>
<name>is_active</name>
<type>boolean</type>
<notnull>1</notnull>
<default>N</default>
</field>
</declaration>
</table>
As you can see, things can get a bit lengthy here as to be expected when using XML. No need to worry: We are working on a browser based tool called MDB_frontend that will make this process much easier. I will talk about this project further down into this article a bit more. Hopefully, the advantage of this pretty verbose representation of the table is that things are somewhat self explanatory. The table in the last example is called users and we have defined 3 fields: user_id of type integer, handle of type text and is_active of type boolean. Remember that MDB handles the type abstraction for you if you pass it the necessary metadata as shown in the previous section. You also need not to worry about what MDB maps these types to in your RDBMS. The other tags you can use in each of the field declarations are optional: length, notnull, unsigned and default.
如你能看到的，如使用 XML 时可以预期的，东西变得有一些冗长。不用担心：我们有一个基于浏览器的工具称为 MDB_frontend 使得这个过程更加简单。我将在这篇文章的后面谈论这个工程。可能这极其详细地表格描述的优点是非常明显。前面例子中的表格被称为 users 并且我们定义了 3 个域：类型为整数的 user_id，类型为文本的 handle 和类型为逻辑型的 is_active。记住如果你如前一节那样传递了必要的元数据 MDB 为你处理类型抽象。你还不需要 MDB 把这些类型映射为你的 RDBMS 中的什么。在每个域声明中还能使用的其他标签是可选的：length，notnull，unsigned 和 default。
The next thing that we now need to do is to ensure that the user_id is unique by placing the proper index on the user_id field. The index definition goes within the declaration tag (Listing 3).
下一件我们现在需要做的事情是通过在 user_id 域放置恰当的索引确保 user_id 是唯一的。索引定义就在声明标签之内（Listing 3）。
Listing 3:
<table>
<name>users</name>
<declaration>
<index>
<unique>1</unique>
<name>user_id_index</name>
<field>
<name>user_id</name>
<sorting>ascending</sorting>
</field>
</index>
</declaration>
</table>
The definition in listing 3 would create a unique ascending index named user_id_index on the field user_id. Of course, we could have specified more than one field in the index definition by simply adding another field tag. What we are still missing now is a sequence to generate unique user id's for us:
在 listing 3 中的定义在域 user_id 中创建一个唯一的上升排序的名为 user_id_index 的索引。当然，我们可以简单地添加另外一个域标签在索引定义中指定多于一个的域。我们现在仍然没有提到的是为我们产生唯一的用户 id 的序列。
<sequence>
<name>users_user_id</name>
<start>1</start>
<on>
<table>users</table>
<field>user_id</field>
</on>
</sequence>
The last example is pretty mind blowing. Going through line by line we see that we first open a sequence tag followed by a name tag which specifies the name of the sequence. This is followed by a start tag that defines the initial value of the sequence. Now, we open an optional on tag. Here we need to set a specific field within a table. This information is used by the manager to set the value of the sequence to the maximum value in the user_id field of the users table. If the users table is empty the value specified in the start tag is used instead. Please note that the value specified in the start tag is the first value that will be returned if you call MDB::nextId().
上一个例子非常的绕弯。一行行看过来，我们看到首先打开一个 sequence 标签，跟着一个指定序列名字的 name 标签。这之后跟着一个定义序列初始值的 start 标签。现在，我们打开一个可选的 on标签。这儿我们需要设置一个表中的指定域。这个信息是管理器用来把序列的值设置为 users 表的 user_id 域的最大值。如果 users 表是空的，作为替代使用的是 start 标签中指定的值。请注意在 start 标签中指定的值是我们调用 MDB::nextId() 返回的第一个值。
Of course, you can also initialize a table with any values. For example you may want to initialize the above table with a maintenance user that you always want to include with your application. To do this we need to add an initialization tag to the table tag. Listing 4 defines one row after another enclosed with an insert tag.
当然，你也能使用任何值初始化表。例如你可能想要用你总是想要包含在你的程序中的管理用户来初始化前面的表格。为了这么做，我们需要把一个 initialization 标签添加给 table 标签。Listing 4 定义了一在另外一用 insert 标签包括的行之后的行。
Listing 4
<table>
<name>users</name>
<initialization>
<insert>
<field>
<name>user_id</name>
<value>1</value>
</field>
<field>
<name>handle</name>
<value>default</value>
</field>
<field>
<name>is_active</name>
<value>Y</value>
</field>
</insert>
</initialization>
</table>
As you can see from the last example all we have to do is to define a value for each field of the table. We now have the necessary basics to create an XML schema for MDB. The next step is to pass this schema file to the MDB manager.
如你从上个例子中能看到的那样，所有我们需要做的就是给表的每个域设定值。我们现在已经知道了必要的基础知识来创建一个 MDB 的 XML schema。下一步是把这个 schema 文件传递给 MDB 管理器。
$manager = new MDB_Manager;
$input_file = 'auth.schema';
// we do not have to connect to a specify a specific database at this time
$dsn = "mysql://$user:$pass@$host";
$manager->connect($dsn);
$manager->updateDatabase($input_file, $input_file. '.before');
We now have a new database called auth with a table called users. There is one index on the field user_id. There is one row in the table as well. We also have a sequence called users_user_id which will be initialized at 1. The next value in the sequence will therefore be 2. Finally, a copy of the schema was created with the name auth.schema.before. This happened because we passed the optional second parameter to MDB_Manager::updateDatabase(). In the next section we will see why this copy is created.
我们现在有了一个新的名字叫 auth 的数据库，它有一个表叫 users。在域 user_id 有一个索引。而且在表中还有一行。我们还有一个序列称为 users_user_id，它将被初始化为 1。因此序列中的下一个值就是 2。最后，schema 的一个拷贝以名字auth.schema.before 被创建。这是因为我们给 MDB_Manger::updateDatabase() 传递了可选的第二个参数。在下一节我们将看到为什么要创建这个拷贝。
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 c
