以前プロジェクトに取り組んでいたときは、lamp、controller/model/db を使用していましたが、モデル内のデータベース操作は実際には SQL ステートメントを直接記述していました。その後、一部の企業やプロジェクトがモデル内で一時的に mysql から mango に切り替えました。実際には、sqlserver には LIMIT がありません。ドライバーを変更すると、元のハードコーディングされた SQL がハングする可能性があります。その後、ActiveRecord/ORM というものがあり、PHP フレームワークとは独立した ORM フレームワークもあることを知りました。しかし、これは大量のオブジェクトを生成し、テーブルの関連付けや複雑なステートメントはあまり便利ではないことがわかりました。 。
私は後になるまでクエリ ビルダーの概念を知りませんでした。例:
リーリー次のように実装されます:
リーリーこのようにして目的は達成されたのでしょうか?
1. 組版が改善され、読みやすくなりました
2. データベースドライバーから独立しているため、ドライバーを変更するときにハードコードされた SQL が実行されなくなります
しかし、次のようなまだ理解できない部分もあります:
リーリーは次のように書くこともできます:
リーリーただし、次の方法は上記の方法よりも読みにくく、間違いを犯しやすくなります。 。特定のデータベースドライバーがASを使用しないようにASを削除して、他のキーワードを独自に実装できるようにするためのものでしょうか?しかし、そうではありません。上記の記述方法が存在することが許可されており、他の人は上記の型を記述しているため、この記述方法は AS のみをサポートするドライバーに限定されるのではありませんか?
同様に、thinkphp の neq => <>、nin => などもあります。Yii はまだ好きです/好きではありません。
このような詳細な結合を実装するlaravelもあります:
リーリー異なるデータベース間の結合に違いはありますか?なぜこれほど詳細に実装する必要があるのでしょうか?引用符とカンマは直接結合ステートメントを記述するよりも面倒ではないでしょうか?それに比べて読みにくいですか?
クエリビルダーを実装する目的がドライバーを切り替えても実行することである場合、文字列を field() または join() に直接渡すのをやめて、代わりに配列または複数のパラメーターを渡してすべてのキーワードを削除する必要がありますか?文字列入力が許可されているため、移植性が損なわれていませんか?
解決策を見つけてください!
以前プロジェクトに取り組んでいたときは、lamp、controller/model/db を使用していましたが、モデル内のデータベース操作は実際には SQL ステートメントを直接記述していました。その後、一部の企業やプロジェクトがモデル内で一時的に mysql から mango に切り替えました。実際には、sqlserver には LIMIT がありません。ドライバーを変更すると、元のハードコーディングされた SQL がハングする可能性があります。その後、ActiveRecord/ORM というものがあり、PHP フレームワークとは独立した ORM フレームワークもあることを知りました。しかし、これは大量のオブジェクトを生成し、テーブルの関連付けや複雑なステートメントはあまり便利ではないことがわかりました。 。
私は後になるまでクエリ ビルダーの概念を知りませんでした。例:
リーリー次のように実装されます:
リーリーこのようにして目的は達成されたのでしょうか?
1. 組版が改善され、読みやすくなりました
2. データベースドライバーから独立しているため、ドライバーを変更するときにハードコードされた SQL が実行されなくなります
しかし、次のようなまだ理解できない部分もあります:
リーリーは次のように書くこともできます:
リーリーただし、次の方法は上記の方法よりも読みにくく、間違いを犯しやすくなります。 。あるデータベースドライバーが AS を使用しないように AS を削除し、他のキーワードを独自に実装できるようにするためでしょうか。しかし、そうではありません。上記の記述方法が存在することが許可されており、他の人は上記の型を記述しているため、この記述方法は AS のみをサポートするドライバーに限定されるのではありませんか?
同様に、thinkphp の neq => <>、nin => などもあります。Yii はまだ好きです/好きではありません。
このような詳細な結合を実装するlaravelもあります:
リーリー異なるデータベース間の結合に違いはありますか?なぜこれほど詳細に実装する必要があるのでしょうか?引用符とカンマは直接結合ステートメントを記述するよりも面倒ではないでしょうか?それに比べて読みにくいですか?
クエリビルダーを実装する目的がドライバーを切り替えても実行することである場合、文字列を field() または join() に直接渡すのをやめて、代わりに配列または複数のパラメーターを渡してすべてのキーワードを削除する必要がありますか?文字列入力が許可されているため、移植性が損なわれていませんか?
解決策を見つけてください!
フレームワーク設計の意味は、開発者の観点から検討されるべきではありません。
フレームワークとしては、ユーザーとプロジェクトのニーズがわからないため、その特性を維持しながらコードで互換性を考慮する必要があるため、すべての DB パッケージはクエリ ビルダーの提供に基づいてクエリおよび実行メソッドをサポートしています。
さらに、デザインがどれほど優れていても、開発者がそれを無差別に使用することを止めることはできません。多くの人はドキュメントを注意深く読まず、文字列形式をサポートするパラメータを見ただけで満足して、それ以上調査しようとしません。たとえば、例では結合を使用しましたが、通常はモデルでデータの関係を定義できるため、結合する必要はまったくありません。
おっしゃるとおり、配列を使用すると移植性が失われます。問題は、コードを自分で書くことです。手間と移植性のどちらを選択しますか。フレームワークの設計者があなたのために決定するわけではありません。