Une ASTUCE pour stocker les données peu courantes sans modifier la structure de la table

[indigene]

Parfois vous avez besoin de stocker une info pour un article dans des cas très rares (par exemple 1 pour 1000).
On peut avoir besoin de stocker cette info rapidement et la mettre en place rapidement.

Comment faire ?

Solution classique :
- modifier la structure de la table pour ajouter un champ
- modifier tous les scripts de création et de modification d'un article pour y ajouter ce champ dans les formulaires
- modifier les ordres INSERT et UPDATE
- modifier tous les scripts qui font des SELECT pour ajouter ce champ quand on en a besoin
- prier pour ne pas faire d'erreur
- tout tester

L'astuce qui va vous faire gagner beaucoup de temps et de sécurité dans sa mise en place

Dans vos tables article ou produit vous pouvez prévoir un champ fourre-tout qui vous servira à stocker tout et n'importe quoi par l'intermédiaire de codifications de style bbcode.
J'avais par exemple mes méta-description qui étaient générées automatique à partir du titre et de la petite description (genre chapô). Mais j'ai eu besoin d'y permettre, pour certains articles, des méta description spécifiques, par contre je n'avais aucun champ dans ma base pour stocker cette info méta_spécifique.

Sans modifier aucun script de la console d'administration j'ai simplement ajouté dans mon champ "fourre-tout" les informations sous cette forme :

[D]l'information spécifique que je veux mettre en meta description[/D]

L'information est encadrée par des balises [D] et [/D] et je peux utiliser d'autres infos dans le même champ fourre-tout, encadrées, elles, par d'autres balises. Chaque balise correspond à une fonctionnalité particulière. C'est par exemple dans ce champ que j'y colle mes TAGs avec les balises [k1]...[/k1], [k2]...[/k2] etc....

Dans le script de formatage de l'affichage, l'instruction à mettre pour extraire ce qui se trouve entre les balises [D] et [/D] est la suivante :

$DOC_DESC_SPE1 = stripslashes(strip_tags($prod['fourre_tout']));   
preg_match('#\[D\](.+)\[\/D\]#isU', $DOC_DESC_SPE1, $DOC_DESC_SPE);

Et voilà, j'ai mon information extraite de mon champ fourre_tout, je peux en faire ce que je veux et je n'ai absolument pas eu besoin de modifier quoi que ce soit d'autre et en particulier la structure de ma base de données.
Il faut simplement prévoir ce champ dès le départ et l'intégrer aux scripts de création/modification et aux formulaires.

Ca permet d'économiser beaucoup de place en base et de conserver une simplicité quand il s'agit de champs qui sont utilisés que pour une très faible population de produits ou d'articles.

 

[spout]

Tu peux aussi utiliser le modèle "EAV": http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model
Ou alors un HSTORE en PostgreSQL: http://www.postgresql.org/docs/9.3/static/hstore.html
Ou tout autre soluce "NoSQL" / "Schemaless".

 

[indigene]

Merci pour les infos, je ne connaissais pas ces modèles,
mais en MySQL il existe des solutions autres que la mienne ? Moi j'aime bien, en 30 minutes je peux ajouter ce que tu veux pour une utilisation ponctuelle pour quelques articles de ma base sans faire aucune modification profonde de structure. Je pourrais même y mettre des données XML ou des fragments de XML (mais il vaut mieux utiliser les crochets pour éviter les erreurs d'affichage)

 

[spout]

mais en MySQL il existe des solutions autres que la mienne ?

EAV

Sinon tu px aussi enregistrer du JSON en DB, mais si tu dois filtrer ta query c'est pas vraiment faisable.

 

[indigene]

Mais ça oblige à modifier les scripts d'administration pour insérer les nouvelles données, non ?
Là j'ajoute ce que je veux, sous forme de baratin, et ensuite je l'utilise sur la page d'affichage qui va bien, je n'ai même pas à ajouter un champ dans le SELECT car il s'y trouve déjà.

Par exemple si dans une boutique en ligne j'ajoute un nouvel article qui correspond à une législation bien particulière et que je veux afficher dans la fiche de l'article un bel encart écrit en rouge (sans avoir à inclure l'encart dans la description de tous les articles qui sont dans ce cas), je vois difficilement méthode plus simple :
- J'ajoute dans mon champ fourre-tout : [LP]1[/LP] par exemple, pour indiquer qu'il s'agit d'une législation particulière
- j'écris ma fonction qui va afficher l'encadré en rouge
- Dans la page d'affichage, j'extrais la donnée avec le preg_match et si elle est présente j'appelle la fonction que je viens d'écrire.

Ca reste bien entendu qu'une astuce mais qui peut servir de temps en temps. Il faut juste prévoir ce champ fourre-tout ou "commentaires additionnels" dès le départ pour se ménager la possibilité d'utiliser cette astuce bien pratique je trouve. On peut aussi s'en servir avec le champ "description" mais ça oblige à bien nettoyer la description à chaque fois pour ne pas que le truc entre crochet ne s'affiche sur toutes les descriptions de produits ou dans les articles. Avec un champ complémentaire fourre-tout c'est plus propre.

 

[Marie-Aude]

Parfois vous avez besoin de stocker une info pour un article dans des cas très rares (par exemple 1 pour 1000).
On peut avoir besoin de stocker cette info rapidement et la mettre en place rapidement.

C'est là qu'on voit à quel point WP est bien fait custom filtre + filtre sur the_content() et ça se fait les doigts dans le nez ^^

 

[indigene]

Désolé mais je vois pas bien le rapport avec WP. Tu parles d'un filtre, c'est un filtre à l'affichage lors d'une recherche ?
Là je parle d'une donnée stockée en table qui va me permettre de la traiter avec un morceau de code particulier dédié à cette donnée. Ca n'a rien d'un filtre.
C'est comme ça que j'ai résolu le problème de mes balises meta-description spécifiques dont on parlait en MP l'autre jour
Sur cette page la balise méta description provient de mon champ complémentaire où j'ai mis la méta entre des balises [D]...[/D] pour le récupérer plus tard à la génération de la page. Tu peux faire la même chose avec WP et son fameux filtre ?

 

[Marie-Aude]

En fait comme tu ne connais pas wordpress tu ne vois pas le rapport

les "filtres" sont des fonctions toutes faites qui permette d'ajouter automatiquement au contenu d'un article "ce qu'on veut", y compris le contenu d'un champ personnalisé qui se créé "à la volée" dans l'admin, sans aucune programmation.

Il faut donc exactement 4 llignes de code pour faire ça

 

[indigene]

oui mais le champ est ajouté au contenu, il n'est pas traité spécifiquement.
Je pense par exemple à une boutique en ligne qui nécessiterait pour certains articles une nouvelle variable. Déjà une boutique ne se développe pas trop en WP.
Mais c'est vrai que je ne connais pas WP. J'avais télécharger la V2 pour voir, vu qu'il y avait déjà 600 scripts pour faire ce que je fais en à peine 30 j'ai vite remballé. C'est bien pour l'utilisateur lambda qui ne connait pas trop la programmation. Mais quand on créé soit même sa propre base de donnée SQL et son code spécifique on peut largement se passer de WP, même si c'est le moins lourd et le plus adaptable des CMS.

 

[Marie-Aude]

Pourtant WooCommerce fait des belles boutiques ^^ et puis tu as les attributs, etc...

La v2, tu es en retard, on en est bientôt à la v4
Les "600 scripts" sont justement là pour gérer la flexibilité et la souplesse du contenu, les vérifications, les normalisations, la gestion de l'interface admin. Honnêtement, je ne pense pas que je ne connais "pas trop" la programmation ^^

 

[indigene]

oui mais nous ne sommes pas dans le forum wordpress
Tiens, d'ailleurs, il existe un forum facebook sur WRI mais aucun forum WP

 

[Wiam]

Bonjour,

La meilleure solution c'est de ne jamais utiliser des "select" partout dans le code, il faut structurer son code... Utiliser une classe, un model, le mieux c'est l'ORM ; de cette façon ajouter un champs dans la base de données, c'est facile et ne demande quasiment pas de modification côté PHP.

Sinon si on a pas le choix, et s'il faut un champ "data", j’opterais pour "serialize et unserialize", j'ai fais plusieurs tests,y compris avec JSON, XML et autre... serialize est le plus rapide même sur les gros tableaux (données), au passage c'est qu'utilise PHP par défaut pour stocker les données des sessions.

 

[zeb]

oui mais nous ne sommes pas dans le forum wordpress

La question n'est pas là, Marie Aude te signale juste qu'il y a une fonction similaire a ta technique dans WP ...
Cela ne fait que renforcer la crédibilité de ta technique que perso je contourne allègrement en ajoutant un champ ou je veux quand je veux en fin de table vu que tout est écrit pour justement ne pas dépendre du nombre de champ ...