1

私が取り組んでいる PHP プロジェクトでは、複数のデータベース プラットフォームをサポートするためにいくつかの DAL 拡張機能を作成する必要があります。これに関する主な落とし穴は、プラットフォームが異なれば構文も異なることです。注目すべき MySQL と MSSQL はまったく異なります。

これに対する最善の解決策は何ですか？

以下は、私たちが話し合ったいくつかの例です。

クラスベースの SQL 構築

これには、SQL クエリを少しずつ構築できるクラスを作成することが含まれます。例えば：

$stmt = new SQL_Stmt('mysql');
$stmt->set_type('select');
$stmt->set_columns('*');
$stmt->set_where(array('id' => 4));
$stmt->set_order('id', 'desc');
$stmt->set_limit(0, 30);
$stmt->exec();

ただし、単一のクエリにはかなりの数の行が含まれます。

SQL 構文の再フォーマット

このオプションははるかにクリーンです。SQL コードを読み取り、入力言語と出力言語に基づいて再フォーマットします。ただし、解析に関する限り、これははるかに遅いソリューションであることがわかります。

4

4 に答える 4

1

クラスベースの SQL 構築をお勧めし、 Doctrine、Zend_DbまたはMDB2をお勧めします。ええ、単純な選択を書くためにもっと多くの行が必要な場合でも、少なくともパーサーに頼ることができ、車輪を再発明する必要はありません.

DBAL を使用することは速度のトレードオフであり、データベースの実行だけではありませんが、これらのいずれかを初めて使用するときは、実際に慣れたときよりも苦痛になります。また、生成されたコードが最速の SQL クエリではないことはほぼ 100% 確信していますが、それは前述のトレードオフです。

最終的にはあなた次第なので、私はそうしませんし、不可能ではないことは確かですが、独自の DBAL を実装することで (長期的に) 時間とリソースを実際に節約できるかどうかという問題は残ります。

于 2008-10-19T15:16:34.243 に答える
1

それをサポートする一連のバックエンドがある場合は、ストアド プロシージャを生成してコントラクトを形成することが最善の方法であることに同意します。ただし、ストアド プロシージャに関して機能が制限されているバックエンドがある場合、このアプローチは機能しません。その場合、アブスタクション レイヤーを構築して SQL を実装するか、抽象/制限された SQL 構文に基づいてターゲット固有の SQL を生成します。

于 2008-10-19T15:24:43.713 に答える
1

解決策は、次のような ID を使用して、プラットフォームごとに異なるクエリ セットを用意することです。

MySql: GET_USERS = "SELECT * FROM ユーザー"

MsSQL: GET_USERS = ...

PgSql: GET_USERS = ...

次に、起動時に必要な一連のクエリをロードして参照します

Db::loadQueries(プラットフォーム):

$users = $db->query(GET_USERS)

于 2008-10-19T12:27:04.817 に答える
1

このようなスキームは、SQL が提供するすべての機能を考慮していないため、各 DB のすべてのテーブルに対してコード生成のストアド プロシージャを使用することをお勧めします。

よりデータベース モデルに対応したパラメータ化されたストアド プロシージャを使用する場合でも (つまり、結合を行うか、ユーザーを認識し、各ベンダーに最適化されます)、それは依然として優れたアプローチです。私は常に、データベース インターフェース レイヤーは単純なテーブル以上のものをアプリケーションに提供すると考えています。

于 2008-10-19T12:39:47.083 に答える