Discussion :

[Alexandre T]

Bonjour,

Voici le cahier des charges : Je dispose d'une base de données pour gérer les données d'un jeu. Dans ce jeu il y a des cités et des ressources et des batiments. Chaque cité est composé de constructions et de stock.

Mon schéma est celui-ci

table cite(id_cite,...)
table ressource(id_ressource,cod_ressource)
table batiment(id_batiment,cod_batiment)

Pour la quantité de ressource stockée dans chaque cité, je mémorise cela dans la table stock. Et pour les batiments de chaque cité, je mémorise cela dans la table construction.

table stock(id_cite,id_ressource,n_stock)
table construction(id_cite,id_baiment,n_construction)

Pour connaitre le cout de construction d'un batiment en ressource, je fais appel à la table cout

table cout(id_batiment,id_ressource,n_cout)

Pour le moment quand la cité 47 construit le bâtiment numéro 3, la méthode est la suivante :
Une première requête vérifie que la cité possède toutes les ressources nécessaires.

Une requête récupère la quantité de chaque ressource nécessaire pour la construction.
(exemple : 24 bois (id 1), 350 sous(id 2), 17 pierres (id 3))
pour chaque ressource nécessaire, un curseur met à jour la table stock et décrémente l'enregistrement n_stock le stock. Donc dans notre cas cela fait trois requêtes. Mais pour certains bâtiments je peux avoir 20 à 25 ressources nécessaires...

Une dernière requête met à jour (incrémente) dans la table construction le champ n_construction de l'enregistrement ayant pour clef cité 47 et batiment 3.

Donc ma question est : Voyez-vous comment je peux supprimer ce curseur qui génère de nombreuses requêtes et le remplacer par une seule requête de mise à jour (un seul UPDATE sur la table stock en somme).

Mon moteur est MySQL, mais cela on s'en moque, je cherche à toujours suivre les normes SQL.

[Admin]

Bon je vais peut-etre dire de la merde mais déjà tu peux faire une seule requete pour vérifier que tout est en stock :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT n_stock-n_cout AS Déficit
FROM cout INNER JOIN stock ON cout.id_ressource = stock.id_ressource
WHERE stock.id_cite=[Cité?] AND n_stock-n_cout<0 AND cout.id_batiment=[batiment ?];

Si la requete ne retourne rien, les quantités en stocks sont suffisantes.

Ensuite la requete de mise à jour qui soustrait ce qui à été utilisé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
UPDATE cout INNER JOIN stock ON cout.id_ressource = stock.id_ressource SET stock.n_stock = n_stock-n_cout
WHERE stock.id_cite=[Cité?] AND cout.id_batiment=[batiment ?];

[Alexandre T]

L'inner join sur l'update m'ennuie un peu. Ce n'est pas trop dans la norme à ce que je sache, mais la méthode est pas mal, je vais tester en début de semaine prochaine.

Par contre, la première requête est on ne peut plus simple, j'avais pris le problème à l'envers. Sélectionner par requête ce qui manque est bien plus rapide que de sélectionner ce dont j'ai besoin et de tester le stock par la suite ! Grand merci !

[Admin]

Si si le INNER JOIN fait partie de SQL2

[Alexandre T]

Si si le INNER JOIN fait partie de SQL2

Oui, oui mais je ne pensais pas qu'elle acceptait pour un update !

Bon je pars déjà avec cela et vais devoir adapter ma requête à mysql qui lui a une syntaxe différente pour des updates "multitables". C'est étonnant de la part de ce moteur contenu de la politique de MySQL.AB... mais bon

Merci bien

[Alexandre T]

Juste pour corriger une boulette que j'ai annoncée...

MySQL 5 gère très bien les INNER JOIN d'un UPDATE !

Merci mon code est maintenant très léger et se limite à 3 requêtes !