最新のMVCフレームワークには、SQLステートメントを記述する必要のない独自のデータアクセスレイヤーの実装があります。パフォーマンスとスケーラビリティの観点から、たとえば、使用する場合の欠点はありますか
$user = User::where('email', '=', $email)->first();
のような生のSQLでプリペアドステートメントを使用する代わりに
$user = DB::connection()->pdo->prepare("SELECT * from users where `email` = ? " ) ;
LaravelやCakephpなどのMVCフレームワークでも後者のアプローチが可能であるため、パフォーマンスとスケーラビリティの点で2つの方法のどちらが優れているかはわかりません。
Rant：「最新のMVCフレームワーク」
と呼ばれるもの（いくつかの例外を除く）は、MVCの実装にほど遠いものです。そして、これらの「SQLステートメントを必要としないレイヤー」は、大規模なプロジェクト（MVCを実際に使用する必要がある場合）では実際には非常に有害です。
私のアドバイスは、組み込みのORMやクエリビルダーの使用を避けることです。いわゆる「mvcフレームワーク」がバンドルされているORMは通常、アクティブレコードの実装であり、ユースケースは非常に限られています。基本的に、ドメインエンティティのARベースの実装は、基本的なCRUD操作（sまたは他の初級レベル以上のSQLクエリなし）と単純な属性検証（クロスチェックされたフィールドや他のエンティティとの相互作用なし）のみを使用している場合にのみ実用的です。技術的には、より複雑なケースでアクティブレコードインスタンスを使用できますが、そうすると技術的負債が発生し始めます。JOIN
最良のオプションは、ドメインロジックをストレージロジックから分離し、モデルレイヤーの各側面にそれぞれドメインオブジェクトとデータマッパーを実装することです。
はい、パフォーマンスとスケーラビリティの両方の点で欠点があります。
これらのORMとARはすべて、基本的なクエリでのみ非常に優れています。
しかし、いくつかの複雑な問題になると、それらは耐え難い複雑になるか、単に無力になります。
これらの洗練された演算子に「USEINDEX」や「DELAYED」などのパフォーマンスを向上させるコマンドを挿入する方法はありません。
スケーラビリティについても同じことが言えます。
非標準の演算子を使用するたびに、頭をかきむしります。
移植性の問題もあります。
SQLはウェブデウェロパーのための共通語であり、誰もがそれを読み書きすることができます。プロプライエタリORMはそれらを修正することができますが。
それにもかかわらず、2番目のコードは醜くて使用できません。
$user = DB::connection()->pdo->prepare("SELECT * from users where email=?");
DB::connection()->pdo->prepare()ユーザーを返しません。実際のユーザー情報を取得するために次の数行で使用する必要があるステートメントハンドルを返します。
スクリプトに大量の役に立たないコードを追加します。
そして、それはスカラーから選択する通常のケースです。INSERTまたは単なるステートメントで試してみるIN()と、コードが数画面の高さまで爆破されます。
本当にユーザー情報を取得するためにそれを作らないのはなぜですか？
$user = DB::conn()->getRow("SELECT * from users where email=?s",$email);
見てください-あなたはあなたのSQLをまだ使用可能にしています。
もちろん、クラスを実行してクエリを組み立てるオーバーヘッドは常にあります。
それでも、エラーを防ぐのに役立ちます。「were id=」のようなタイプミスは発生しません（または発生しないはずです）。それを除いて、それらのレイヤーはすでにあなたのためにたくさんのことをします。
エスケープ、解析、検証などのように...オーバーヘッドを取りますが、多くの障害やセキュリティの問題が発生しないことを確認してください