PEAR MDB データベース抽象化レイヤー 一度書けばどこでも実行可能
- WBOYオリジナル
- 2016-06-21 09:08:591064ブラウズ
データ|データベース
一度書いたらどこでも実行
一度書いたらどこでも実行
これは Java のマーケティング スローガンですが、PHP の重要な機能の 1 つでもあります。多くのビジネス モデルは、製品を幅広い顧客ベースに販売できるようにするために、オペレーティング システムの独立性に依存しています。では、なぜ特定のデータベース ベンダーと結びつくのでしょうか?データベース抽象化レイヤーを使用すると、データベースから独立してアプリケーションを開発できます。ただし、多くの場合、これらは期待以上にパフォーマンスに影響を及ぼしたり、データベース固有のコードをすべて削除できるほど抽象的ではありません。
この記事は何を教えてくれますか?
この記事では、データベース抽象化パッケージ PEAR MDB について詳しく説明します。この記事の焦点は、データ型の抽象化や XML ベースのスキーマ管理など、同様のパッケージで提供される機能を超える MDB のより高度な機能にあります。 PHP と SQL の基本的な理解を推奨します。
なぜ別のデータベースクラスが必要なのでしょうか?
通常、Web プロジェクトは、顧客が使用する RDBMS (リレーショナル データベース管理システム) を決定した後、既存の IT インフラストラクチャに追加されます。予算の違いによって、展開するデータの選択に影響が出る可能性があるため、そうではありません。結局のところ、開発者としては、特定のベンダーに縛られたくないだけかもしれません。それ以来、サポートされている各データのバージョンを維持するか、より多くのパフォーマンスを犠牲にして必要以上に使いやすさを向上させることを意味します。PEAR MDB を導入してください。
MDB は、RDBMS に依存しない PHP プログラムの作成を簡単なプロセスにすることに重点を置いたデータベース抽象化レイヤーです。 PHP の他のいわゆるデータベース抽象化レイヤーのほとんどは、サポートされているすべてのデータベースと非常に限定された抽象化 (主にシーケンスのみ) に共通の API を提供します。一方、MDB を使用すると、データベースによって送受信されるすべてのデータを抽象化できます。データベース スキーマも RDBMS に依存しない形式で定義できます。ただし、高いパフォーマンスと使いやすさを維持しながら、これらの機能を提供します。これは、2 つの一般的なデータベース抽象化レイヤー、PEAR DB と Metabase を詳しく調べ、それらを統合することによって実現されました。そして、統合プロセス中に、この機会を利用して、統合された API とパフォーマンスに影響を与える設計をクリーンアップしました。
MDBはどのようにして登場しましたか?
2001 年の秋に遡ると、私は会社のプログラミング フレームワーク RDBMS を独立させることができるデータベース抽象化パッケージを探していました。目標は、データベース固有のコードの量をゼロに減らすことです。このような機能を提供する唯一のパッケージは Metabase です。ただし、Metabase の一部には、PHP3 との互換性を保つために不快な API が含まれています。それにもかかわらず、私たちは Metabase が唯一の選択肢であると判断しました。しかし、Metabase にパフォーマンス改善パッチを追加した後でも、パフォーマンスを犠牲にしすぎていると感じていました。私たちは 2001 年の PHP 国際会議で Metabase の作者たちと会い、Metabase のようなものを PEAR プロジェクトの一部にすることの利点について話し合いました。その後間もなく、PEAR DB とメタベースを統合することで考えられる利点について、PEAR メーリング リストで別の議論が始まりました。社内で何度も議論を重ねた結果、この仕事を引き受けることにしました。数か月にわたる懸命な作業を経て、MDB の最初の安定版リリースが完成しました。
MDB は何を提供しますか?
MDB は、PEAR DB とメタベースのほとんどの機能を組み合わせています。実際、現在存在しない PEAR DB の唯一の機能は、結果セットとしてオブジェクトを返すことです。この機能は一般的に使用されておらず、パフォーマンス上のペナルティが非常に明らかであるため、この機能は削除されました。 API をできる限り使いやすくするために、多くの開発時間が費やされています。最終的に、MDB はこれらの機能を非常に高度に提供し、少なくとも PEAR DB と同じくらい高速で、Metabase よりも大幅に高速です。これらの最も重要な機能のリスト:
OO スタイル API
事前に準備されたクエリ シミュレーション
データベースに出入りするすべてのデータの完全なデータ型抽象化 (LOB サポートを含む)
トランザクション サポート
データベース/テーブル /インデックス/シーケンスの作成/discard/change
RDBMS に依存しないデータベース スキーマ管理
PEAR フレームワークに継承 (PEAR インストーラー、PEAR エラー処理など)
それでは、どのように使用するのでしょうか?
MDB は、非常に高度な抽象化機能をいくつか提供します。これらの機能はオプションのみであることを覚えておくことが重要です。ただし、RDBMS に依存しない PHP プログラムを作成する場合は、これらを使用することが非常に重要です。 MDB の使用がいかに簡単であるかを示す例は、この記事の最後にある「リンクとドキュメント」セクションにあります。前述したように、この記事の焦点は、MDB を他の PHP データベース抽象化レイヤーと区別する機能を紹介することです。これらすべてのサンプル スクリプトのコードは、この記事に同梱されている CD に収録されています。
ただし、その前に MDB をインストールする必要があります。これは実際には、PEAR インストーラーを使用すると非常に簡単です。この記事では PEAR インストーラーについて完全に説明することはできませんが、次号では PEAR フレームワークの詳細について詳しく説明する予定だと聞いています。インストーラーを Windows 上で実行できるようにする作業が進行中ですが、サポートはまだ少し不安定です。 *nix システムの場合、システムに CGI バージョンの PHP をインストールする必要があり、次のコマンドを実行するだけです:
lynx -source go-pear.org|php
インストールが完了したら、あと 1 つ入力するだけです。コマンド行 これですべて完了です。
pear install MDB
前のプロセスがうまくいかない場合は、PEAR MDB ホームページからパッケージを直接入手するオプションが常にあります。 URLは記事末尾に記載しております。
データ型の抽象化を使用する
ほとんどのデータベースには何らかの個性や癖がある傾向があるため、MDB にとってこれらの違いを開発者から隠すことは非常に重要です。 MDB は、独自の内部データ型 (テキスト、ブール、整数、10 進数、浮動小数点、日付、時刻、タイムスタンプ、ラージ オブジェクト (ファイル)) を定義することでこれを実現します。データベースとの間でやり取りされるすべてのデータは、MDB の内部形式との間で変換できます。このセクションに関連するサンプル スクリプトは、datatype ディレクトリにあります。次のクエリを見てみましょう:
$session = '098f6bcd4621d373cade4e832627b4f6'; $query = 'SELECT createtime, user_id FROM session';
$query .= ' WHERE session = '.$session;
$query .= ' AND lastaccess < '.$timeout;
このクエリがデータベースに送信された場合、失敗する可能性があります。その理由は、$name に格納されている値を正しい文字列形式に変換する必要があるためです。これは、$name の内容に特殊なエスケープ文字が含まれているか、引用符で囲まれている可能性があることを意味している可能性があります。 PEAR DB は、この目的のためにメソッド DB:.quote() を提供します。 MDB では、このメソッドは MDB::getTextValue() と呼ばれます。違いは、MDB が前にリストした各データ型に対してそのような関数を提供していることです。したがって、$timeout を正しい形式に変換することもできます。
// $timeout を MDB タイムスタンプ形式に変換します
$timeout = MDB_date::unix2Mdbstamp($timeout);
// データ型変換の仕組みを示す SELECT クエリ
$query = 'SELECT createtime, user_id FROM session';
$query .= ' WHERE session = '.$mdb->getTextValue($session);
$query .= ' AND lastaccess < '.$mdb->getTimestampValue($timeout);
例として、最初の行のみを取得したいと仮定します。 MDB::queryRow() は最初の行を取得し、結果セットを解放してその内容を返します。これはまさに私たちが望んでいることです。
$result = $mdb->queryRow($query);
しかし、RDBMS が異なれば、日付などのデータを返すために使用する形式も異なります。したがって、何らかのデータに対して計算を実行する場合は、選択した RDBMS に関係なく、同じ形式でデータを返すことが重要です。これは、MDB によって半自動的に実行できます。必要なのは、結果の列がどの型になるかを指定することだけで、MDB が変換を処理します。最も簡単な方法は、そのような情報をクエリ関数に渡すことです。
$types = array('timestamp', 'integer');
$result = $mdb->queryRow($query, $types);
これは、結果セットの最初の列の型が次であることを MDB に伝えます。 'timestamp '、2 番目の列は 'integer' です。すべてのクエリ関数は、このようなメタ情報をオプションのパラメーターとして受け入れることができます。 MDB::setResultTypes() を使用して、後からデータを設定することもできます。データの取得元のデータベースに応じて、データはそれに応じて変換されてデータが返されます。 MDB 内のタイムスタンプのデータ形式は ISO 8601 標準に従います。 PEAR::Date などの他のパッケージはこの形式を処理できます。 MDB は、MDB_Date クラスでいくつかのデータ形式変換関数も提供しており、これをオプションで含めることができます。
多くの RDBMS は同様に整数データを返すため、整数データを変換する必要はありません。したがって、パフォーマンスをわずかに向上させるには、次のようにすることができます:
$types = array('timestamp');
$result = $mdb->queryRow($query, $types);
この方法は次のとおりです。結果セットの最初の列のみが変換されます。もちろん、MDB を使用してさまざまなデータベースから整数を返す場合、これが問題になる可能性があります。ただし、わずかなパフォーマンスの向上はリスクに見合う価値がない可能性があります。しかし、繰り返しになりますが、これらの機能の使用はオプションにすぎないことがわかります。
リスト 1 は、準備されたクエリの使用例を示しています。これは、データがデータベースに渡されることが唯一の違いであるが、クエリの構造は同じである多数のクエリを実行する必要がある場合に非常に便利です。高度なデータベースでは、解析されたクエリをメモリに保存してパフォーマンスを向上させることができます。
リスト 1
$alldata = array(
array(1, 'one', 'un'),
array(2, 'two', 'deux'),
array(3, 'three', 'trois '),
array(4, 'four', 'quatre')
);
$p_query = $mdb->prepareQuery('INSERT INTO数値VALUES (?,?,?)');
$param_types = array('integer', 'text', 'text');
foreach ($alldata as $row) {
$mdb->execute($p_query, NULL, $row, $param_types);
}
$alldata に格納されている 4 つの配列はすべて、execute ステートメントで使用されます。データは自動的に正しい形式に変換されます。これは挿入ステートメントであるため、データ型を設定する必要がある結果列がないため、MDB::execute() の 2 番目のパラメーターは NULL に設定されます。
サポートされているデータ型の中には、データベースにファイルを保存できる LOB (ラージ オブジェクト) があります。バイナリ ファイルは BLOB (バイナリ ラージ オブジェクト) に格納され、通常のテキスト ファイルは CLOB (キャラクタ ラージ オブジェクト) に格納されます。 MDB では、準備された INSERT クエリと UPDATE クエリを使用してのみ LOB を格納できます。 MDBA::setParamBlob() または MDB::setParamClob() を使用して、準備済みクエリ内の LOB フィールドの値を設定できます。どちらの関数も、MDB::createLob() を使用して作成できる LOB オブジェクトが渡されることを想定しています。
$binary_lob = array(
'Type' => 'inputfile',
'FileName' => './myfile.gif'
);
$blob = $mdb->createLob($binary_lob);
$character_lob = array(
'Type' => 'data',
'Data' => 'これは CLOB データの非常に長い文字列コンテナになります'
);
$clob = $mdb-> createLob($character_lob);
ご覧のとおり、MDB::createLob() にはリレーショナル配列が渡されます。 Type キーの値は、data、inputfile、outputfile のいずれかになります。最初の 2 つは、LOB をデータベースに書き込む場合に使用されます。 LOB が変数に格納されている場合は、inputfile を使用する必要があるときにファイルから LOB を直接読み取る必要があります。最後に、データベースから LOB を読み取る場合は、outpufile を使用する必要があります。 data と inputfile のどちらを使用しているかに応じて、上記の例のように、Filename キーまたは Data キーの値を指定する必要があります。ここで、以前の LOB をデータベースに保存します。
$p_query = $mdb->prepareQuery('INSERT INTO files (id, b_data, c_data) VALUES (1, ?, ?)');
$mdb->setParamBlob($p_query, 1 , $blob , 'b_data');
$mdb->setParamClob($p_query, 2 , $clob, 'c_data');
$result = $mdb->executeQuery($p_query);
を取得するにはデータベースからのデータ 上記のファイルを取得するには、まずデータベースからデータを選択し、MDB::createLob() を使用して LOB オブジェクトを作成する必要があります。今回は「Type」を「outputfile」に設定します
$mdb->query('SELECT b_data FROM files WHERE id = 1');
$binary_lob = array(
'Type' => 'outputfile' './ myfile2.gif'
);
$blob = $mdb->createLob($binary_lob);
これで、MDB::readLob() を使用して結果セットから LOB を読み取ることができるようになりました。 MDB::readLob() に長さ 0 を渡すことは、LOB 全体が読み取られ、前に指定したファイルに保存されることを意味します。タスクが完了したら、リソースを解放できます。ゼロより大きい任意の長さを設定し、while ループを使用して MDB::endofLob() をチェックして LOB を読み取ることもできます。
$mdb->readLob($blob, $data, 0);
これはほとんどの PHP で機能するため、このフェッチ関数を MDB::fetchAll() のような一括フェッチ関数と混同しないように注意してください。データベースの拡張時に問題が発生します。場合によっては、MDB は一括取得関数を使用して LOB を取得できる場合があります。
このセクションで説明したように、MDB 機能自体のネイティブ データ型のセットは、データベース内のネイティブ データ型に自動的にマッピングされます。これにより、データベースとの間でどのようなデータを送受信しても、使用する RDBMS に関係なく同じ形式になることが保証されます。このセクションの冒頭ですでに述べたように、これには明らかに、データベースが MDB が予期するデータ型を使用する必要があります。この必要性は、マッピングのコストを確実に小さくするために使用されます。次のセクションでは、データベース内で正しいデータ型の使用を MDB がどのように支援するかを説明します。
XML スキーマ ファイルの使用
前の段落で説明した機能を使用すると、真にデータベースに依存しないプログラムを作成できます。しかし、MDB はさらに一歩進んで、XML でスキーマを定義できるようにします。マネージャーは、このスキーマを各 RDBMS に必要な SQL ステートメントに変換します。これは、サポートされているすべての RDBMS で同じスキーマを使用できることを意味します。このセクションの例は、xml_schema ディレクトリにあります。
XML スキーマ ファイルを最初から作成します。まず、XML ドキュメントを定義する必要があります。データベース定義はデータベース タグに含まれます。データベースの名前は、name タグを使用して定義されます。 create タグは、データベースが存在しない場合にデータベースを作成する必要があるかどうかをマネージャーに伝えます。スキーマ ファイルを複数のファイルに分割する場合は、最初にマネージャーに送信するファイルで create を 1 に設定します。
おそらく、データベース名 auth から、このデータベースの目的は、簡単な認証手順のためのユーザー データを保存することであると推測できます。リスト 2 は、ユーザー データを保存できるテーブルを定義します。
リスト 2
ご覧のとおり、XML を使用する場合に予想されるように、処理は少し冗長になります。心配しないでください。このプロセスをさらに簡単にする MDB_frontend と呼ばれるブラウザベースのツールがあります。このプロジェクトについては、この記事の後半で説明します。おそらく、この非常に詳細な表形式の説明の利点は明白です。前の例のテーブルは users と呼ばれ、整数型の user_id、テキスト型のハンドル、および論理型の is_active の 3 つのフィールドを定義しました。前のセクションのように必要なメタデータを渡すと、MDB が型の抽象化を処理することに注意してください。これらの型を RDBMS 内の何かにマップするために MDB はまだ必要ありません。各フィールド宣言で使用できる他のタグはオプションです: length、notnull、unsigned、default。
次に行う必要があるのは、user_id フィールドに適切なインデックスを配置して、user_id が一意であることを確認することです。インデックス定義は宣言タグ内にあります (リスト 3)。
リスト 3:
リスト 3 の定義は、フィールド user_id に user_id_index という名前の一意の昇順インデックスを作成します。もちろん、別のフィールド タグを追加するだけで、インデックス定義に複数のフィールドを指定できます。まだ言及していないのは、一意のユーザー ID を生成するシーケンスです。
最後の例は非常に回りくどいです。これを 1 行ずつ見てみると、最初にシーケンス タグが開かれ、次にシーケンス名を指定する name タグが続いていることがわかります。これに、シーケンスの初期値を定義する開始タグが続きます。ここで、オプションの on タグを開きます。ここでは、テーブルに特定のフィールドを設定する必要があります。この情報は、シーケンス値をユーザー テーブルの user_id フィールドの最大値に設定するためにマネージャーによって使用されます。 users テーブルが空の場合は、開始タグで指定された値が代わりに使用されます。開始タグで指定された値は、MDB::nextId() の呼び出しによって返される最初の値であることに注意してください。
もちろん、テーブルを任意の値で初期化することもできます。たとえば、プログラムに常に含めたい管理ユーザーを使用して前のテーブルを初期化することができます。これを行うには、テーブル タグに初期化タグを追加する必要があります。リスト 4 では、insert タグに含まれる別の行に続く行を定義しています。
リスト 4
前の例からわかるように、必要なすべてがすべてテーブルの各フィールドに値を設定します。これで、MDB の XML スキーマを作成するために必要な基本が理解できました。次のステップでは、このスキーマ ファイルを MDB マネージャーに渡します。
$manager = new MDB_Manager;
$input_file = 'auth.schema';
// 現時点では特定のデータベースを指定して接続する必要はありません
$dsn = "mysql://$user:$pass @$host";
$manager->connect($dsn);
$manager->updateDatabase($input_file, $input_file. '.before');
これで、auth という新しい名前がデータベースに追加されました。 users というテーブルがあります。 user_id フィールドにはインデックスがあります。そしてテーブルには別の行があります。また、1 に初期化される users_user_id というシーケンスもあります。したがって、シーケンス内の次の値は 2 になります。最後に、スキーマのコピーが auth.schema.before という名前で作成されます。これは、オプションの 2 番目のパラメーターを MDB_Manger::updateDatabase() に渡したためです。次のセクションでは、このコピーが作成される理由を説明します。
これらはすべて非常に素晴らしいですが、さらに良くなります。多くの場合、プログラムのどこかを変更する必要があります。たとえば、テーブルの名前を users から people に変更する必要があると判断する場合があります。パスワードフィールドを保存するためにフィールド pwd を追加する必要がある場合もあります (テキストボックスの予約語を確認してください)。
予約語
このフィールドをパスワードと呼ばなかった理由は、それが Interbase のドメイン名の予約語だからです。 RDBMS の独立性が必要なため、fail_on_invalid_names オプションが true (デフォルト) に設定されている場合、MDB マネージャーは警告を発するか失敗します。
過去には、あなたは今、すでに持っているすべてのものをこの新しいスキーマに変換することに苦労しているかもしれません。しかし、MDB のおかげで、これらのタスクは自動的に実行できます。リスト 5 には、テーブル定義に加えた変更を示します。 ;field>
$input_file = 'auth.schema';
$manager->updateDatabase($input_file, $input_file.'.before');
これですべてです。 users テーブルは people と呼ばれるようになり、pwd ドメインも追加されました。
XML スキーマ形式の最後の機能を見ていきます。この機能は、マネージャーをプログラムで使用する場合に特に重要です。データベース サーバー上で同じバリデータを実行している複数のクライアントがあるとします。 各クライアントには、同じスキーマを使用してサーバーが実行されていますが、わずかな違いはデータベース名だけです。更新サイクルが同じではない可能性があるため、クライアントごとに個別のスキーマ ファイルを保存することが現実的である可能性がありますが、このサンプル バリデータの場合は当てはまりません。ここにあるすべてのクライアントは同時に更新されます。 XML スキーマ ファイルを使用すると、これに変数を使用できます。
< /database>
今度は、実行時に変数を必要なものに設定します。
foreach($clients as $name) {
$variables = array('name' => $name)
$manager->updateDatabase($input_file, $input_file.'.before', $variables);
}
XML スキーマ管理は、MDB が提供するデータベース抽象化のもう 1 つの非常に重要な部分です。これにより、特定の RDBMS に依存しないスキーマ定義を維持できます。ただし、この形式を使用すると、MDB がネイティブ データ型を正しくマップできるように、正しいネイティブ データ型が使用されることも保証されます。最後に、データは XML に基づいているため、XML スキーマ ファイルを生成または読み取るツールを作成するのが簡単です。
素晴らしく聞こえますが、私のアプリケーションはすでに...
ほとんどの読者は、すでに他のデータベース抽象化レイヤーで多数のプログラムが実行されている状況に陥っているかもしれません。 MDB の起源により、MDB の API は PEAR DB に基づいているため、PEAR DB のほとんどのユーザーは、MDB が非常に似ていると感じるはずです。メタベース ユーザーは、自分が好むすべての機能が MDB に対応するものであることに気づくはずです。 XML スキーマの形式は Metabase の形式とまったく同じです。すでに作成されたプログラムを MDB に移植するための完全なガイドはこの記事の範囲を超えていますが、この機会にいくつかのヒントを紹介します。具体的なご質問がございましたら、お気軽にメッセージをお送りください。
PEAR DB プログラムを MDB に移植するには、PEAR ラッパーから始めるのが最適です。 PEAR ラッパーを使用してプログラムを実行できます。ラッパーは確かに追加のオーバーヘッドを追加するため、ネイティブ インターフェイスに移行したくなるかもしれません。したがって、最初のステップは、プログラムで現在使用されているすべての PEAR DB 関数をリストすることです。次に、ラッパーを調べて API の違いを見つけます。注意すべき重要な違いが 2 つあります。結果セットはオブジェクトではなくなり、結果セットのデータ型を渡すことができるすべてのクエリ メソッドでは、パラメーターの順序がわずかに変更されます。最初の違いは、結果オブジェクトに対して get 関数を呼び出すことができないことを意味します。
$result = $db->query($sql);
$row = $result->fetchRow();
次に、MDB オブジェクトを呼び出してフェッチする必要があります:
$result = $mdb- >query($sql);
$row = $mdb->fetchRow($result);
2 番目の違いは、ラッパーを観察することで簡単に解決できます。ラッパーでわかるように、MDB が結果セットのデータ型を期待する場所に NULL を渡すだけで済みます。これで、プログラムで MDB を使用できるようになります。もちろん、現時点では MDB の高度な機能の恩恵を実際には受けられません。これには、現在のデータベース スキーマにいくつかの変更が必要になる可能性があります。マネージャーは、既存のデータベースから XML スキーマ ファイルを逆に取得することを試みることができます。非常に単純なフロントエンドは、MDB パッケージ、reverse_engineer_xml_schema.php スクリプトに含まれています。ほとんどの場合、結果の XML スキーマを手動で修正する必要がありますが、これで良いスタートが切れます。
既存のプログラムを Metabase から MDB に移植したい場合は、すべての関数呼び出しを変更する必要があります。 Metabase ラッパーを見ると、何を変更する必要があるかが明らかになります。正規表現を知っていれば、おそらくこれらの置換のほとんどを実行できるでしょう。いずれにせよ、先に進んで、もともと気に入っていた高レベルの抽象化機能を実行する必要がありますが、現在は MDB を使用しています。関数名が短くなっていることに気づくかもしれません。パフォーマンス テストを実行すると、パフォーマンスが大幅に向上することもわかります。
では、MDB は将来どのようになるのでしょうか?
この記事が公開された時点では、MDB はオリジナルの 1.0 リリースではなくなっている可能性があります。オリジナルの MySQL ドライバーと PostGreSQL ドライバーに続いて、MDB には ODBC ドライバーが追加され、さらに多くのドライバーが追加される可能性があります。これは、MDB 開発中に重点を置く重要な領域の 1 つです。 MDB がドライバーの点で PEAR DB に追いつくと、PEAR フレームワーク内の標準のデータベース抽象化レイヤーになる可能性があります。
しかし、開発にはもう 1 つの重要な領域があります。それは、MDB_frontend プロジェクトです。 MDB_frontend は、MDB および MDB Manager に基づいた phpMyadmin になります。このツールを使用すると、MDB がサポートする RDBMS に格納されているデータベースを参照できるようになります。 MDB_frontend は、ネイティブ データ型と MDB データ型の両方を表示します。 MySQL のシーケンスなどのシミュレートされた機能は非表示になります。ユーザーには、シーケンス参照を格納するテーブルではなく、シーケンスのリストのみが表示されます。これにより、MySQL でシーケンスがシミュレートされます。また、MDB_frontend は、既存のデータベースを移植して、MDB が使用することが予想されるネイティブ データ型に準拠するのに役立ちます。 XML スキーマ ファイルの作成と更新にも役立ちます。いくつかの初期作業は完了しましたが、公開前に多くのことを追加する必要があります。
ドライバーと MDB_frontend はすべて現在の開発の焦点ですが、ユーザーが MDB に必要とするものは他にもたくさんあります。LOB フィールド統合の一括取得など、外部キーと主キーのサポートが必要な場合もあります。いつものように、テストと実装に参加すると、オープンソースのものは大幅にスピードアップします。ただし、機能リクエストなどのフィードバックも歓迎します。
記事後の感想
数か月にわたる努力の結果、MDB は現在の PEAR DB およびメタベース ユーザーの間で受け入れられるようになりました。また、現在他のデータベース抽象化レイヤーに納得していないユーザーにも、MDB がもたらすメリットを理解してもらえることを願っています。もちろん、RDBMS の特別な調整を必要とするプログラムは依然として多くありますが、MDB のようなツールでは単に不必要な追加の負担と制限が追加されるだけです。全体として、社内で MDB の開発を主導するという決定に非常に満足しています。最初は、PEAR DB と Metabase の両方のユーザーを満足させようとすると、どこにいてもやや不愉快な結果になるのではないかと少し心配していました。もう 1 つの懸念材料は、PHP コミュニティがその開発を支援してくれるかどうかです。 PHP コミュニティが来て、ドライバーと MDB のコアの作成を手伝ってくれたことをとてもうれしく思います。したがって、私たちはこのプロジェクトが大成功であると考えています。また、MDB もさらに改善されると考えています。そして、私たちは PHP の向上を支援することに喜びを感じています。
著者について
Lukas Smith は PEAR DB の主著者です。彼は複数の PHP Kaiyuan プロジェクトに積極的に貢献しており、PHP 開発に重点を置いている会社 BackendMeida の創設者でもあります。
リンクとドキュメント
PEAR MDB ホームページ: http://pear.php.net/package-info.php?package=MDB
PEAR MDB ドキュメント: http://www.backendmedia.com/MDB/docs/
PEAR MDB サンプル スクリプト: http://cvs.php.net/co.php/pear/MDB/MDB_test.php
PEAR DB ホームページ: http://pear.php.net/package-info.php?package= DB
メタベースのホームページ: http://www.phpclasses.org/mirrors.html?page=%2Fbrowse.html%2Fpackage%2F20.html
簡単なベンチマーク: http://freshmeat.net/screenshots/30313/