Bonjour,

A plusieurs reprises je suis tombé sur une syntaxe inconnu...

Voici la requête :
Ce qui m'intrigue, c'est la valeur du champ `serial`...

Vous connaissez ce type de syntaxe ?

Charles

hello,

Apparemment c'est un tableau sérialisé (donc simplement transformé en chaine de caractères par la fonction serialize() ).
tu pourra en récupérer le contenu en déserialisant la donnée avec userialize().

tu pourra en récupérer le contenu en déserialisant la donnée avec userialize().

Petite coquille, c'est unserialize() le nom de la fonction de désérialisation

oups !

je vais me fouetter de ce pas avec des orties !
ça m'apprendra a pas me relire...

Ha ok

C'est assez pratique si on souhaite stocker un grand nombre de données sans devoir les traiter via mysql...



Enfin, c'est plutôt utile pour le développement objet

C'est en effet très pratique dans certains cas, mais c'est à utiliser avec précaution.
En théorie, il est fortement déconseiller de stocker un tableau dans un champ de base de donnée. (voir un cours sur le design de base de données, et la normalisation pour plus de détails)

Dans la pratique, c'est utile si on veut stocker un tableau et récupérer tout le tableau par après pour l'utiliser dans son ensemble. Par contre si par après, on doit rechecher un élément du tableau, cela devient très lourd de devoir récupérer tout le tableau en php, pour ensuite le parcourir à la main, dans ce cas, il vaut mieux normaliser la base de donnée, et avoir une table supplémentaire, ce qui permettra de récupérer directement la donnée précise qu'on recherche.

A utiliser avec précaution. Mais ça peut être sacrément utile.

Exemple réel : une base de données d'entreprises. Au moyen d'un formulaire, chaque utilisateur peut poser des filtres sur ses centres d'intérêt, du style : les entreprises de nano-technologies des régions Normandie et Alsace qui exportent vers le Japon et les USA et qui ont une croissance de CA de +10% (et encore je fais simple ...)
Sans la sérialisation des tableaux, c'est quasiment impossible de stocker les critères de chaque filtre dans une base de données normalisées. Par contre, les entrepriseses et tout ce qui gravite autour est bien sûr normalisé.

Effectivement, il n'y a pas de recherche sur les éléments du tableau, sauf très exceptionnellement un boss qui se pose la question "combien d'utilisateurs ont posé des filtres sur le japon". et là, avec un like sur le tableau sérialisé, on arrive à retrouver. Mais ça reste exceptionnel.

En plus, c'est évolutif car lorsqu'un nouveau critère est mis en place dans le formulaire de filtrage, il n'y a aucune modification de la base à faire.

Soit je n'ai pas bien compris ce que tu exposes, soit je suis un dieu ... et malgré mon pseudo, je penche pour la 1ere solution

Pour reprendre ton exemple :
1 table PERSONNEL
1 table CRITERE_FILTRE
et 1 table d'association entre ces 2 tables

En quoi cette solution n'est pas normalisée ?
De plus, tu veux rajouter un critère, tu insert une ligne dans la table CRITERE_FILTRE et il est désormais possible pour chaque personne de l'ajouter à sa liste de critères ...

Mais je pense que je n'ai pas du comprendre ton exemple

Je pense que ce que voulait dire Henri c'était qu'il était très difficile de faire une recherche par critère sur des données "live". Dans ton exemple, zeus, quand une société cesse d'exporter vers le Japon il faut effacer l'entrée correspondante dans ta table d'association. On pourrait toutefois argumenter que ça peut être fait par un TRIGGER.

C'est vrai qu'une telle solution nécessite de définir quels sont les critères exacts et maintenir une table d'association, mais d'un autre côté les performances n'ont rien à voir avec celles de requêtes sur des données dénormalisées.

On pourrait imaginer une table permettant de représenter les différents filtres/critères sous forme de SQL pour pouvoir générer des requêtes spécialisées. Par exemple, pour trouver les entreprises qui exportent vers les USA et le Japon on ajouterait ...le tout avec des marqueurs pour indiquer où mettre certaines variables (par exemple le "10" de "10%", etc...). Le moteur serait plutôt complexe, mais pas tellement plus qu'un truc qui ouvre tous les enregistrement et applique ses propres filtres.

Si le sujet vous intéresse, je n'ai pas vraiment trouvé de liens mais ça doit faire partie du domaine de l'ontologie (mot-clé connexe : "IR" pour "Information Retrieval", "ontology").

Edit: ah ben si j'ai fini par trouver un lien chez Wikipédia: http://en.wikipedia.org/wiki/Ontology_% ... science%29 et http://fr.wikipedia.org/wiki/Ontologie_ ... matique%29

je me suis sûrement mal exprimé.
La base de données est bien sûr parfaitement normalisée : les pays d'exportation sont liés aux entreprises par des relations n-n, de même que les secteurs d'activités et tout le reste.

Je ne parlait que du stockage du filtre. Et là, je me moque de le normaliser parce que les éléments individuels du filtre ne m'intéressent pas. Le filtre est un ensemble de données qui est écrit et lu comme un tout. Je n'ai pas besoin de lire individuellement les éléments du filtre.

De même, les moyens d'accès sont toujours dans le même sens : je lis les filtres d'un utilisateur, puis pour un filtre donné, je lis tous les critères d'un seul coup. Je n'ai pas besoin non plus de trouver tous les filtres posés sur une entreprise ou sur un pays (ou alors c'est tellement anecdotique que cela ne compte pas).
C'est également une question de performances : je lis une chaîne de caractères dans un seul champs dans une seule table.

En PHP, dans cette application, un filtre est un tableau d'un nombre quelconque de critères dont chaque élément peut lui-même être un tableau. Avant l'enregistrement dans la base de données, l'application utilise ce tableau pour faire ses filtrages (pour générer le SQL de lecture des entreprises avec l'application des filtres). Après enregistrement et lecture dans la base de données, l'application utilise ce même tableau. A quoi cela sert-il de décomposer le tableau en valeurs élémentaires pour le stockage sachant que 1) on n'utilise pas individuellement ces valeurs élémentaires 2) on doit les recomposer exactement à l'identique après relecture. Autant stocker la structure d'un seul coup. En plus, cela réduit les risques de bugs en évitant d'écrire du code qui va déstructurer, puis restructurer le tableau.

Je vais faire une analogie : un texte structuré est une sorte de tableau ou plutôt d'arbre. Des chapitres, des sous-chapitres, des paragraphes, des alinéas, ...

Si mon besoin est une application qui puisse manipuler ou gérer ces éléments individuellement (par exemple, une application de génération de contrats d'assurance avec des clauses type), alors il faudra que la structure de ma base de données contienne des tables chapitres, sous-chapitres, ... et qu'il y ait des relations entre les éléments des tables.
En revanche, si mon besoin est que l'utilisateur puisse saisir un texte formatté, le stocker et le relire comme un tout (un message dans un forum ou dans un blog), alors il suffit d'un seul champ texte avec des balises type HTML, SPIP ou bbcode et que l'on stocke dans un seul champ d'une seule table.

Voila, j'espère avoir été un peu plus clair.

Effectivement, ton explication sur les filtres m'a bien éclairé et j'adhère à ton point de vue