1

私の考え：

私は、コスト、スケーラビリティ、互換性など、さまざまな理由からストアド プロシージャを絶対に軽蔑しています。

  • コスト: 優れた MySQL サーバー 1 台のコストで、2 ～ 3 台の優れた軽量 Web アプリケーション サーバーを入手できます。

  • スケーラビリティ: 確かにクエリ結果をキャッシュすることはできますが、ストアド プロシージャを使用すると、キャッシュできる内容をより細かくする機会が失われます。また、アプリケーションが常に MySQL を使用することになります (ストアド プロシージャを書き直すためのお金を持っている人はいません)。 MySQL を別のものに?)

  • 互換性: ある時点で list_foo_widgetsByUser() ストアド プロシージャがクライアント #123 のニーズに合わない可能性があります。list_foo_widgetByUser() の署名を変更するのは自殺行為です...そのため、新しい sproc cl123_list_foo_widgetByUser() を作成する必要があり、その方法は狂気または殺人 DBA につながります。

私の解決策：

アプリケーションのリポジトリからモデルを取り出し、外部リポジトリに配置します。すべてのアプリケーションには、外部リポジトリを指す models/Base サブディレクトリがあります。次に、baseFooWidget クラスをインスタンスまたはアプリケーション固有の子インスタンスとして返す GetModel("FooWidgets") のような単純なファクトリ メソッドを前に置きます。これにより、個々のアプリケーションが FooWidget のクラスを継承したり、Liquabase などのツールと組み合わせたりして、より大きな可変性の基盤を実現できます。

頭の後ろで「これは簡単すぎる」という声が聞こえます...何が欠けているのでしょうか?

参考文献: 私は、PHP Kohana フレームワークがこれらの線に沿って何かを行って、アプリケーション設計者が機能を追加して Kohana の基本ライブラリをラップできるようにすることを知っています.PHP がそれを行うことができれば、他の言語に問題があるとは思えません.

4

1 に答える 1

3

ストアド プロシージャをなくすのは素晴らしい考えです。3 つのポイントで正確に釘を打ちます。

一方、PHP は、構造化されたラッピングを簡単には許可しません。私は PHP 中毒者ではありませんが (C# / Java のほうが好きです)、これに取り組む最善の方法は、データベース/ドメイン/アクセス/ビジネス レイヤーを分離することです。要するに：

  1. 下部: データベース。テーブル、リレーション、それだけです。
  2. 次に、テーブルを表す単純なオブジェクトであるマッピングが必要です。通常、テーブルごとに 1 つのオブジェクト。
  3. 次に、これらのオブジェクトを処理するメソッドが必要です。ほとんどのテーブルには、「get all」、「get by id」、および「save」メソッドが必要です。理想的には、これらは別のモジュールに入るため、マッピングを変更する必要なく開発できます。
  4. 最後に、ビジネス ロジックが必要です。これは、別のレイヤーまたはアプリケーションに入れることができます。

これは簡単な概要です。あなたのソリューションでこれを意味したかどうかはわかりませんが、これは通常、懸念の分離です。データベースを変更する場合は、マッピングを変更するだけで済みます。別の結果セットが必要な場合は、アクセス レイヤーのみを変更します。

このプロセスに役立つツールは Hibernate です (ただし、JavaBridge が必要です)。これは最適な ORM ツールですが、学習曲線が少し急です。PHP の場合、Doctrine が多くのことを実行できるようです。他のツールも存在します。理想的には、ツールはラウンドトリップ エンジニアリングを可能にします。何かを変更した場合は、ツールを再度実行 (または何かを変更) し、アプリケーションを壊すことはありません。

于 2009-10-17T17:54:50.920 に答える