2

増え続けるクエリのリスト (ほとんどすべての "SELECT" クエリ) をどこに配置し、アプリ全体でそれらに適切にアクセスする方法は?
現在、アプリ内のサービス全体にクエリが散りばめられているアプリをリファクタリングしようとしています。既に作成した他のクエリと同様の小規模および大規模なクエリがある場合、DRY の問題が発生し始めています。また、それらのクエリで同じフォーマットを何度も書き直している場所もあります。選択したデータベースを置き換えることについては心配していませんが、後でクエリを最適化することについて心配しています。すべてのクエリをより適切に整理せず、中央の場所に保管しておくことで、それがほぼ不可能になったのではないかと考えています。OOP と SoC の優れたプラクティスに従いたいと考えています。

現在アプリでクエリを実行している場所の例
たとえば、特定のイベントのすべてのスタッフの PDF (またはコンテンツ) を提供するサービスがあります。このサービスには、いくつかの入力 (「ソート」、「フィルター」、「ページネーション制限」など) を受け入れるメソッドがあり、10 個のテーブル結合を使用してクエリを実行します (クエリは、ほとんどの処理の前に管理可能な行数までかなりうまくスライスされます)。 JOIN はその上で動作します)、PDF に必要な方法で結果をフォーマットします。

これまでに計画したこと
オブジェクトに関してデータベースのニーズを完全に考えようとして苦労しています。すべてが完全にアドホックではなく、多くの JOIN と WHERE を含む幅広い SELECT を使用して、多くの柔軟なクエリを実行しますが、最善を尽くしています。

  1. ドメイン オブジェクトusersEntity: (データベース内eventsEntityの各マッチ テーブル) のようなクラスを作成し、、、、などのidプロパティを設定します。データベース テーブルのフィールドと一致します。変更できるようにゲッター/セッターを作成する場合があります（日付などの形式を設定したり、検証を実行したりします）。データベース内の 1 つのテーブルを実際には表さないエンティティを作成することもありますが、アプリ全体で頻繁に再利用するデータの共通コレクションを表す場合があります。またはと呼ぶかもしれません。namephoneusersCollectionusersEvents

  2. Data Mapper : したがって、すべての CUD (作成、更新、削除、読み取りではなく、おそらくfindByIdusersMapperを除く) 操作を配置し、それらを、などと呼ばれるクラスに格納しましeventsMapperた。マッパーは、1 つのタイプのドメイン オブジェクト (上記の #1 を参照) のみを受け入れ、永続性を処理します (および、findById($id)またはのような非常に基本的な読み取り/選択の小さなセットfindByEvent($eventId))。

これにより、読み取り (SELECT クエリ) のリストが増え、それらをどこに置くべきか?

私が知っているオプションですが、不十分です。多分私はそれらを誤解しています。

このようなクエリがあるとしましょう

SELECT users.first_name、users.last_name、events.name、events.date、venues.name、
会場の種類.名前, GROUP_CONCAT(user_friends.last_name) を「友達」として
FROM ユーザー
JOIN イベント ON(events.id = users.event_id AND events.date = :date)
JOINなど....

したがって、PHP コミュニティ全体のブログで目にするのは、次の 3 つの選択肢です。

  1. クエリ呼び出しをDoctrine2呼び出しのようなものに置き換えます。彼らの DQL は呼び出しを再利用可能にしていないようですか? そして、5 つのエンティティ (JOIN に基づく) のように、ユーザー、イベント、会場、会場の種類、友人のすべてのプロパティが満たされるように、物事が接続されているようです。必要のないフィールドがたくさんあります。上記のクエリでわかるように、それぞれから 1 つの列が必要でした。また、このようなクエリの後にエンティティを保存する予定はありません。

  2. すべてのクエリ呼び出しを、次のようなメソッドを持つリポジトリクラスに置き換えます$someUserRepo-> findNameAndEventNameAndEventDateAndVenueNameAndVenueTypeNameAndFriends()。本当にクレイジーなメソッド名に加えて、ここで何を渡すか (条件: sort、limit、いくつかの where ?) や何を返すか (arrays? objects?) がわかりません。

  3. クエリビルダーを使用して、すべてのクエリ呼び出しをORM呼び出し (Laravel の Eloquent など)に置き換えます。SQL クエリをplease->ORM->build->this->for->me->where->andWhere->andWhere->I->dont->know->SQL. ところで、私は ORM がアンチパターンであるとほぼ確信していますか?

これは、PHP コミュニティ全体で非常に複雑な問題であると思われます。または、ここで何が欠けていますか？

4

1 に答える 1