| 一次编写，随处运行 |
| 责任编辑：育鹰 更新日期：2005-8-6 |
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 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);
}
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上一页 [1] [2] [3] [4] [5] 下一页 |
|
| 上一篇文章： xml+php动态载入与分页 |
| 下一篇文章： 用libTemplate实现静态网页的生成 |
|
|
|
|
