Bonjour,

Je dispose de deux tables, l'une nommée Bande étant la liste de bande avec ses caractéristiques et l'autre, nommée Booked registre les réservations propres à chaque bande. Actuellement pour connaître le nombre de réservation (la somme des quantités réservées) et l'afficher je fais SELECT SUM(Quantity) FROM Booked WHERE BandNumber = 47 (47 étant pour l'exemple).

Seulement, j'aimerai savoir si il n'était pas mieux d'incrémenter la valeur "Booked" (= nombre de réservation) dans la table Bande lors de l'ajout d'une réservation, étant donné que mon site permet d'ajouter les réservations, puis simplement afficher cette valeur.

Qu'en pensez-vous ? Ai-je été assez clair ? Je joins des captures d'écrans (Table Bande suivi de Table Booked) si cela peut vous aider à mieux comprendre.

Merci d'avance

Salut

Je pense que tu devrais pouvoir t'en sortir avec une requête depuis Bande avec jointure vers Booked, un count(Booked.id) (ou assimilé) et un GROUP BY Bande.id, pas besoin d'avoir une colonne qui fait le compte, ça ne se justifie à mon avis pas trop dans ce cas.

C'est vrai que ça parait être une bonne idée ! Y-a-t-il cependant un intérêt à privilégier la solution que tu proposes ? Est-ce plus optimisé ou plus safe, ou je ne sais quoi ? Ou est-ce juste plus "cohérent / logique" ?

Désolé si la question peut paraitre étrange mais j'aimerai vraiment m'améliorer !

Les colonnes qui contiennent un décompte, c'est pratique tant qu'on n'a pas de critère pour compter des enregistrements liés. Si par exemple tu venais à devoir exclure certaines réservations selon un (groupe de) critère(s) précis, tu créerais une nouvelle colonne avec un nouveau nombre ? Mais alors ça en ferait deux à maintenir à chaque opération… et rebelote à chaque nouveau (groupe de) critère(s), donc ce n'est pas nécessairement le mieux. Certes, cela se fait dans certains cas où le nombre d'enregistrements devient suffisamment important pour qu'une requête comme celle que je te propose devienne lente, mais je ne pense pas que ce soit un cas qui doive te préoccuper, moi-même je n'ai pas rencontré de cas où cette nécessité a fait loi.

D'autre part, c'est un des buts des systèmes de gestion de bases de données que de savoir combien d'enregistrements sont retournés et de pouvoir le faire avec GROUP BY, donc ce n'est normalement pas quelque chose qui est gourmand en ressources, d'autant moins si on compte des valeurs d'une colonne indexée, a fortiori celle qui sert de clé primaire pour une table.