(reprise du message précédent)
C'est un très mauvais exemple.
Ça me fait exactement le même effet que si tu m'avais dit "Pourquoi s'embêter à mettre un <h1> pour un titre alors que ça marche très bien avec un <font>? Ridicule, je trouve." 
La modélisation de base de données est probablement la matière la plus théorisée et formalisée en informatique. Respecter ces quelques règles, même si à priori on ne voit pas pourquoi, peut éviter de s'arracher les cheveux à postériori, le jour où on a besoin de modifier la base, ou l'application.
Je plussoie yodaswii : arrêtez de ménager le moteur de base de données, il est là pour ça.
QuentinC a écrit :
Heu... désolé de ramener un contre exemple, mais que fais-tu si tu dois stocker un array de taille variable dans un champ ?
Si on sait qu'on utilise toujours tous les éléments du tableau quand on en a besoin, pour moi, un type text avec de l'implode/explode fonctionne très bien.
Dans un tel cas pourquoi créer une nouvelle table avec deux champs et s'embêter avec deux requêtes au lieu d'une ? ridicule je trouve.
C'est un très mauvais exemple.
Ça me fait exactement le même effet que si tu m'avais dit "Pourquoi s'embêter à mettre un <h1> pour un titre alors que ça marche très bien avec un <font>? Ridicule, je trouve." La modélisation de base de données est probablement la matière la plus théorisée et formalisée en informatique. Respecter ces quelques règles, même si à priori on ne voit pas pourquoi, peut éviter de s'arracher les cheveux à postériori, le jour où on a besoin de modifier la base, ou l'application.
Je plussoie yodaswii : arrêtez de ménager le moteur de base de données, il est là pour ça.
plus deux trois autres modifs sur des champs existant), avec tous les champs ce fut asser rapide à modifier, puisque je n'avait quasiment qu'a ajouter les champs et à mettre des resquest() dans mes scripts, mais aucun traitement complexe à modifier.
?
!