par
Ryle » 30 août 2007, 14:15
Bah tu fais comme tu veux... 4 valeurs dans 4 chmaps c'est juste plus facile à retrouver et à modifier ... Maintenant rien ne t'empêche de concaténer les valeurs reçues dans une seule variable et de la stocker dans ton varchar...
Le seul soucis que tu aurais dans le cas présent, c'est que si l'utilisateur coche les 4 cases, les 4 valeurs mises bout à bout ("VesteSous cuirassePantalonMasque") tiendront jamais dans un champ de 20 caractères
Maintenant à mon avis, mieux vaut une table avec 100 champs utiles, que l'on peut indexer, mettre à jour et interroger facilement, qu'une table avec 20 champs pour des raisons de "beaucoup de champs" qu'il faudra parser, comparer, exploser et remplacer dès qu'on voudra en faire quelque chose

La question est donc de savoir l'usage que tu as de l'info et l'évolution possible de celle-ci.. parce qu'on peut aussi envisager une table avec ta liste de pieces et des id, et une table de liaison pour lier le gars à ses pièces...
Bah tu fais comme tu veux... 4 valeurs dans 4 chmaps c'est juste plus facile à retrouver et à modifier ... Maintenant rien ne t'empêche de concaténer les valeurs reçues dans une seule variable et de la stocker dans ton varchar...
Le seul soucis que tu aurais dans le cas présent, c'est que si l'utilisateur coche les 4 cases, les 4 valeurs mises bout à bout ("VesteSous cuirassePantalonMasque") tiendront jamais dans un champ de 20 caractères ;)
Maintenant à mon avis, mieux vaut une table avec 100 champs utiles, que l'on peut indexer, mettre à jour et interroger facilement, qu'une table avec 20 champs pour des raisons de "beaucoup de champs" qu'il faudra parser, comparer, exploser et remplacer dès qu'on voudra en faire quelque chose :)
La question est donc de savoir l'usage que tu as de l'info et l'évolution possible de celle-ci.. parce qu'on peut aussi envisager une table avec ta liste de pieces et des id, et une table de liaison pour lier le gars à ses pièces...