Dialogue avec le SGBD et complétion d'objets

[Xenos]

Salut,

une question me vient sur l'utilisation du SGBD dans vos projet (jeux ou pas, puisque la question se pose ici au taff): supposons que vous souhaitiez avoir la liste des armes des unités qui se trouve dans la zone visible de votre carte.

Est-ce que vous allez demander au SGBD "donne-moi la liste des cases dans cette zone", le SGBD vous la donne, vous la récupérez coté client (disons coté PHP), puis ensuite, vous construisez une nouvelle requête demandant au SGBD "voici une liste de cases (ids), donne-moi la liste des unités sur ces cases-là", le SGBD vous la donne, vous la re-parsez coté client puis enfin, vous construisez une dernière requête demandant "voici une liste d'unités (ids), donne-moi la liste des armes de ces unités" et vous le re-reparsez coté client ?
Ou bien est-ce que vous avez une autre approche plus légère?

Car dans la 1ere approche, si la liste de cases est grande, la liste d'unités sera grande. Du coup, la 2nde requête (et de fait, la 3e aussi) sera longue, et dépassera le max_allowed_packet sur MySQL ("WHERE IN" avec des milliers de cases puis d'unités dedans) ou l'équivalent PostGre.
Quelle solution utilisez-vous alors? Augmenter le max_allowed_packet? Ou revoir l'architecture du code?

[niahoo]

Tu dois pouvoir configurer ton code pour qu'il fasse des requêtes imbriquées, ce qui permet côté PHP de pouvoir séparer chaque étape en un appel différent mais de n'exécuter qu'une requête sur la base de données.

Mais ensuite l'exemple est pas très bon, car au lieu de récupérer la liste des cases il vaut mieux récupérer directement les unités avec les coordonnées min et max de ta zone.

[Xenos]

La carte n'est pas forcément un plan (x;y) continue: les unités peuvent être considérées comme étant sur "une et une seule case" (sans position X;Y donc), et la case est placée dans le plan à un endroit donné (X;Y). Comme un jeu de plateau (osef dans RISK de savoir quelles sont les coordonnées X;Y d'un soldat, l'unité est simplement "sur une case/région").

Ok, la requête imbriquée me semblait aussi être le plus cohérent; j'étais curieux de voir quelles autres idées pouvaient émerger de la question

[niahoo]

(Bah dans risk tu peux avoir un système de coordonées à 1 dimension. C'est pareil dans N dimensions. Et si pour "une et une seule case" tu veux dire que tu utilises des ID pour les cases, j'espère que tu prévois un moyen de sélectionner des ranges dans cette numérotation.)

[Ter Rowan]

j'ai déjà vu requête imbriquée et "where in" avec une boucle pour faire autant de requêtes secondaires que nécessaire sans dépasser le maximum d'entrées acceptées par le in (donc on ne touche pas à la config de la bdd)

le problème de la requête imbriquée est sa maintenabilité quand tu ne maitrises pas la qualité du développeur (sur un temps de vie d'une application pro, tu vas te retrouver avec assez de turn over pour avoir 2-3 équipes complètement différentes voire plus encore et... probablement pas que du top du top côté sql

le problème du where in, c'est sa performance moindre à priori (par contre plus facile à comprendre par le développeur médiocre)