Discussion :

[Nalexx]

bonjour!

pour stocker des informations de manière très souple, je serialize certaines d'entre elles avant de les envoyer dans le champ correspondant dans ma BDD.

première question : quel est le meilleur type de données à utiliser pour ce champ? Je l'ai mis par défaut en TEXT, mais je ne suis pas sûr du tout que ce soit le must...

seconde question, qui découle de la première : n'y a t'il pas une autre méthode plus optimisée pour faire ça? C'est à dire conserver un nombre, différent suivant chaque entrée, d'informations complémentaires?

3e question bonus : lorsque je veux faire une recherche sur ces fameux champs, je fais donc une recherche avec un %LIKE% sur le champ de l'array serialisée, puis je fetch les résultats, éventuellement avec un levenshtein, pour renvoyer les infos correspondantes.

J'ai un peu peur d'avoir réinventé la roue en mode over non optimisé... vous avez des méthodes plus propres?


J'attends vos réponses avec impatience

Merci

[CinePhil]

C'est complètement anti-BDD ça !

Une BDD relationnelle est basée sur un modèle de données normalisé dont la première forme normale spécifie que les données doivent être atomiques, c'est à dire qu'on ne doit pas stocker plus d'une information dans une colonne de table.

La sérialisation, c'est le contraire puisque qu'on encapsule dans une seule chaîne plusieurs données.

J'ai un peu peur d'avoir réinventé la roue en mode over non optimisé

Effectivement !

vous avez des méthodes plus propres?

Commencez par écrire les règles de gestions des données puis faites un Modèle Conceptuel de Données (MCD, méthode Merise), de préférence avec un logiciel de modélisation (il en existe des gratuits tels que Open Modelsphere ou JMerise) et que vous dériverez en un Modèle Logique de Données ou un diagramme entity/relationship (façpon MySQL Workbench) et vous pourrez enfin générer le code de votre base de données qui sera bien plus performante que votre plat de spagettis sérialisé !

[Nalexx]

Parfait!

merci

[ericd69]

salut,

je vais être plus ouvert...

tu peux vouloir stocker les sessions phpen BD plutôt que dans des fichiers individuels...

c'est un exemple de stockage de données sérialisées...

ce qui importe ici c'est pas les données elles-mêmes, sur lesquels tu n'agiras pas, mais les informations de session qui vont te permettre de les chercher pour les modifier ou les supprimer ou encore les supprimer...

ça fait partie des éternelles discussions sur le stockage de données plus ou moins lourdes en bd ou juste ce qu'il faut pour les identifier et les manipuler et les données, elles, les stocker dans des fichiers...

pour le cas des sessions, ça vaut le coup par exemple, pour le cas d'images (qui sont des structures de données aussi) ça se discute plus... voir c'est carrément contre productif...

d'ailleurs dans les exemples de la doc php est proposé une implémentation de ça

l'idée générale c'est qu'on évite de mettre des données lourdes en terme de taille en BD si on agit pas dessus... maintenant tu trouveras aussi ceux qui argueront que ça permet de se dispenser du système de fichier et de faire un truc cross-platform...