Mysql et savoir faire (la facon propre?)

[japower01]

Bonjour,

Je vais faire un site qui subira des évolutions.
Dans ma base j'ai mes membres inscrit "Nom, Prénom, etc.."

Cette liste d’éléments va fortement augmenter dans le futur. (adresse, etc..)
Je ne souhaite pas pour autant modifier mes scripts php dans leurs actions d’écriture dans la base.

Alors ma questions est simple:
Comment je dois m'y prendre pour que ce soit le plus propre/stable/securité possible?

une colone par variable ? une chaine avec un caractère * entre chaque variable à exploser ?

Merci pour votre lumière.

PS: Je me fait peut etre une fausse idée, les actions PHP peuvent etre ecrites 1 fois pour toute, de facon à agir meme si le tableau a de nouvelles colonnes.

Merci encore pour votre lumière.

[Lordsephiroth]

Bonjour,
À mon avis, quand le modèle de base de données change, le code PHP ou les requêtes SQL de sélection doivent également changer. Ce n'est pas possible d'avoir du changement dans la base sans qu'il n'y ait le moindre impact sur le code PHP, même en utilisant quelque chose comme une étoile séparant les champs dans un seul énorme bloc de texte. Je déconseille d'ailleurs fortement d'utiliser cette solution. Imaginons que le 8 ème élément de votre champ de texte (celui après la 7 ème étoile) devienne un critère de recherche dans votre application : les performances seront absolument horrible car il sera nécessaire de faire une requête avec une directive LIKE %XXX%, ce qui est tout sauf optimal.

Quant à savoir si il est préférable de faire des tables horizontales (une colonne par information) ou verticales (une ligne par information contenant deux colonnes, l'une indiquant le type de l'information, par exemple "nom" et une seconde colonne pour la valeur, par exemple "Toto"), ce débat reste ouvert et dépend de votre application.

Il faut savoir qu'une table verticale sera pratiquement toujours moins performante qu'une table horizontale. Les requêtes complexes seront également plus difficiles à écrire. Par contre, le gros avantage de la table verticale sera de pouvoir ajouter aisément des éléments, tant que l'information ajoutée ne doit pas donner lieu à des recherches ou jointures complexes.

Personnellement, j'utilise des tables horizontales. J'utilise également un outil pour générer un modèle de classe à partir de la structure de la base de donnés pour manipuler les objets (CRUD).

Je ne prétends pas avoir LA solution et si d'autres ont envie de donner leur avis, je serai également intéressé

Salutations,
Patrick

[Djakisback]

Salut,
personnellement je dirais que ça dépend de l'application car générer des requêtes SQL dynamiques depuis une liste de champs n'est pas un problème (même si ça en génère un qui est celui de la sécurité). Cela implique de stocker quelque part ta liste de champs/tables puis de coder des requêtes génériques depuis ce tableau. Ensuite seule la modification du tableau est nécessaire pour changer le comportement de l'appli.

Mais le problème se pose plutôt pour l'affichage et la génération de formulaires pour l'insert et l'update. Il est assez difficile d'être générique à ce niveau, notamment dans la mise en page et surtout dans le choix des composants HTML (input, textarea, select, etc.). Bien que cela doit être possible en récupérant les types des colonnes depuis une requête SQL, le plus simple serait de bien dissocier tes données de leur affichage (du pseudo MVC )

Comme Patrick, je pense qu'il faut bannir le stockage de plusieurs informations dans un même champ et respecter l'atomicité des données, notamment du fait que de bonnes performances passent généralement par la création d'index sur les différentes colonnes d'une table pouvant apparaître dans les clauses where.