Discussion :

[arnofly]

Bonjour tout le monde,

Je suis en train de coder les pages admin d'un site "catalogue" et je n'ai pas encore beaucoup d'expérience, surtout avec les bases de données.

Je me pose une question peut-être un peu bête, mais par précaution, je préfère avoir l'avis d'un vieux de la vieille

Alors voilà, dans ma table de produits, j'ai prévu une colonne pour recevoir un tableau sérialisé qui contiendra tout le tableau html des caractéristiques détaillées du produit. Il n'est pas prévu de faire des recherches sur les caractéristiques des produits dans le site.

En espérant que la méthode soit bonne, je me demande laquelle des 2 options est préférable en terme de perfs et autres éléments que je n'aurais pas pensé à prendre en compte.

Méthode 1 (actuelle)
Je récupère mon array des inputs de chaque nom des labels (colonne gauche du tableau html) et mon array des inputs de chaque valeur des labels (colonne droite du tableau html) que je mets le tout dans un tableau associatif que je sérialise et enregistre dans une unique colonne dans la table de la DB

Méthode 2
- 1 colonne dans la table de la DB pour tous les labels (colonne gauche du tableau html)
- 1 colonne dans la table de la DB pour toutes les descriptions (colonne droite du tableau html)
Chaque colonne de la table recevant un array sérialisé

Si jamais, j'utilise InnoDB comme moteur pour info.

Vous en pensez quoi ?
Merci !

[arnofly]

Je viens de découvrir la fonction FIND_IN_SET. C'est peut-être mieux, non ? J'imagine que ça prendrait moins de place du coup, si je fais un implode pour chaque array d'inputs...

[sabotage]

Pour moi ta méthode 2 ne présente pas d'interêt.
Pour la méthode 1 tu peux être interessé par json_encode() plutôt que serialize(), ça te laissera plus de souplesse sur le format, on ne sait jamais.

Je ne vois pas bien ce que tu veux faire avec FIND_IN_SET mais même si l'encodage du tableau ajoute un peu de données, c'est préférable à vouloir bidouiller un truc maison.

[arnofly]

Merci pour ta réponse.

Pour FIND_IN_SET : je ne savais pas qu'il était possible de faire une recherche dans un array enregistré en base de données. j'ai pas encore pris le temps de regarder si on pouvait l'utiliser avec un array sérialisé.

Sinon, mon interrogation porte en fait sur les performances. Par rapport à mon exemple, l'idée est de savoir s'il est préférable de mettre un seul array sérialisé qui nécessitera plus de traitement php mais et qui demandera peut-être un type MEDIUMTEXT par exemple OU s'il vaut mieux utiliser 2 colonnes de type TEXT qui nécessitent 2 serialize et donc 2 unserialize, mais un traitement php plus simple. Mais bon, je me prends peut-être la tête pour rien

[sabotage]

Ton postulat de départ était que tu ne ferrais pas de recherche.
Si tu n'as même qu'un soupçon de vouloir rechercher, filtrer, trier, abadonne ton idée de champs serialisé.
La vraie bonne structure est une table produit - caracteristique - valeur ; je précise que ce n'est pas plus difficile a mettre en place et gérer que ce que tu veux faire.

[arnofly]

Encore merci.

Oui je te confirme ne pas avoir l'intention d'effectuer des recherches sur les caractéristiques. Je vais rester sur la sérialisation alors, ça me fera toujours une table de moins à gérer.

Les caractéristiques seront toujours différentes d'un produit à un autre dans la grande majorité des cas. Elles sont hyper spécifiques et comme le site est bilingues... ça me ferait encore une table de plus avec ses 2 jointures pour les langues. Et puis tu la fais comment la table en fait ? Sachant que le nombre des caractéristiques et leur formulation est toujours différent d'un produit à un autre, je vois pas comment m'y prendre en fait.

Sinon, sans parler d'intérêt mais de perfs, il y a t-il une différence entre les 2 méthodes stp ? Depuis mon dernier poste, j'ai fait mon bout de code qui fonctionne pour la sérialisation avec la "méthode 1".

[arnofly]

Ton postulat de départ était que tu ne ferrais pas de recherche.
Si tu n'as même qu'un soupçon de vouloir rechercher, filtrer, trier, abadonne ton idée de champs serialisé.
La vraie bonne structure est une table produit - caracteristique - valeur ; je précise que ce n'est pas plus difficile a mettre en place et gérer que ce que tu veux faire.

Tu ferais une table "produits" avec 3 colonnes qui contiendraient toutes les caractéristiques de tous les produits.
Genre :
1. id (clé étrangère qui pointe vers l'id du produit dans une autre table) -> dont le chiffre est répété autant de fois que le nombre de caractéristiques du produit ciblé
2. label (nom du libellé)
3. description (description du libellé)

SI c'est ça ? ça finirait pas par faire une table un peu lourde ?

[sabotage]

Un SGDB est conçu pour gérer des données sous cette forme.
Cependant si tu n'exploites jamais le contenu de ces caractéristiques, c'est sûr que ça perd de son interêt des les compartimenter.

[Meyfarth]

Ca permettrait également d'éventuellement faire évoluer facilement les caractéristiques, de faire des caractéristiques type par catégorie de produits, ...

Imagines que tu veux rajouter une caractéristiques pour tous les produits de type "livre", là tu seras obligé de faire un script qui récupère tous les livres, unserialize, modifie le tableau et serialize à nouveau. C'est loin d'être évident ou facile. Avec une BDD un peu mieux structurée, il te suffirait à la limite de remplir un tableau csv (id_produit, nouvelle_caractéristiques, valeur) que tu ré-importes via phpMyAdmin par la suite.

Un conseil basé sur quelques années d'expérience : si tu es persuadé que ça ne va jamais changé, c'est qu'en général tu te trompes. Tu finis toujours par y revenir. Fais un peu plus de travail maintenant pour t'épargner des heures de galère plus tard, ça vaut mieux.