Une requête complexe vs plusieurs requêtes simples

Question

Qu'est-ce qui est réellement mieux? Avoir des classes avec des requêtes complexes chargées de charger par exemple des objets imbriqués? Ou des classes avec des requêtes simples responsables de charger des objets simples? Avec des requêtes complexes, vous devez aller moins dans la base de données, mais la classe aura plus de responsabilités.

Ou des requêtes simples où vous devrez aller plus à la base de données. Dans ce cas, cependant, chaque classe sera responsable du chargement d'un type d'objet.

La situation dans laquelle je suis est que les objets chargés seront envoyés à une application Flex (DTO).

Answer 1

La règle générale est que les allers-retours au serveur sont coûteux (par rapport à la durée d'une requête type), le principe directeur est donc que vous voulez les minimiser. Fondamentalement, chaque jointure un-à-plusieurs peut potentiellement multiplier votre jeu de résultats, donc la façon dont j'aborde ceci est de continuer à rejoindre jusqu'à ce que le jeu de résultats devienne trop grand ou que le temps d'exécution de la requête soit trop long. En fonction de votre plate-forme, vous pouvez ou ne pouvez pas exécuter des requêtes en parallèle. C'est un déterminant clé dans ce que vous devriez faire parce que si vous ne pouvez exécuter qu'une seule requête à la fois, l'obstacle à la fragmentation d'une requête est beaucoup plus élevé.

Il est parfois utile de conserver certaines données relativement constantes dans la mémoire (informations sur le pays, par exemple) ou de les traiter séparément, mais cela est, selon mon expérience, raisonnablement inhabituel. Il est beaucoup plus fréquent d'avoir à réparer des systèmes avec des performances affreuses en grande partie à faire des requêtes distinctes (en particulier les requêtes corrélées) au lieu de jointures.

Answer 2

D'un sentiment de l'intestin, je dirais:

Go avec la manière simple tant qu'il n'y a pas de raison éprouvée pour optimiser la performance. Sinon, je mettrais l'approche "objets complexes et requête" dans le panier d'optimisation prématurée.

Si vous trouvez qu'il y a de réelles implications en termes de performances, vous devriez optimiser l'arrondi entre Flex et votre backend à l'étape suivante. Mais comme je l'ai déjà dit: C'est un instinct, vous devriez vraiment commencer avec une définition de «performant», commencer simple et mesurer la performance.

Answer 3

Je ne pense pas que toute option est réellement mieux. Cela dépend de votre application spécifique, de l'architecture, du SGBD utilisé et d'autres facteurs.

E.g. nous avons utilisé plusieurs requêtes simples dans notre solution autonome. Mais lorsque nous avons développé notre produit vers une solution légère et accessible via Internet, nous avons découvert que notre infrastructure générait énormément de requêtes et que la performance de la latence du réseau s'en trouvait affectée. Nous avons donc suffisamment retravaillé notre cadre pour l'utilisation de requêtes complexes agrégées. Pendant ce temps, nous avons maintenu notre solution autonome et sommes passés d'Oracle Light à Apache Derby. Et une fois de plus, nous avons constaté que certaines de nos nouvelles requêtes complexes devraient être simplifiées car Derby les a effectuées trop longtemps. Alors, regardez votre vrai problème et résolvez-le de façon appropriée. Je pense que les requêtes simples sont bonnes pour commencer s'il n'y a pas d'objectifs forts contre eux.