Boujour à tous,
 
Je ne sais plus dans quel post j'ai lu que la personne sérialisait un objet et l'insérait ensuite en base.  
Quelqu'un pourrait-il me dire dans quel but cela est intéressant ?
 
Merci d'avance,
Lionel.

tu peux sauvegarder un objet avec toutes ses variables par cette méthode, et ainsi le récupérer tel quel

 
Euh... oui, je veux bien, mais dans quel but ?    
Peux-tu me donner un exemple concret où l'on aurait besoin de sérialiser un objet et de l'insérer en base ?
 
En fait, sauf erreur, il me semble que la personne que je cite dans mon premier message, avait créée un objet DVD dont elle renseignait plusieurs attributs via le constucteur. J'ai compris que c'était un tru du genre :
 

 
Vu cet exemple, je me demandais donc pourquoi ne pas créer une table "DVD" avec tous les champs adéquats ?!  

Si tu créais une table DVD avec les champs adéquats, tu serais obligé en retour, de recréer tes objets en lisant ta base de données. Un objet sérialisé, quand tu le "désérialises",ça donne un objet directement. Plutot que de sauvegarder la description de l'objet détaillée, tu sauvegardes directement l'objet en lui meme

Mouais, c'est peut-être pas super de sérializer un truc pareil Si t'as une recherche à faire par exemple, c'est carrément naze

ba tout dépend de l'utilité, de comment tu renseigne ta base de données.
Mais ça peut être util de récupérer un objet tel qu'il était, notament pour le faire persister tout au long d'une session... cepepndant j'aurais utilisé une variable de session pour enregistrer la sérialisation dedans.
 
Toujours est il que ça a un intérêt dans certain cas

C'est super stupide dans 99% des cas, quand même...
Ta base de données elle ne peut plus te servir qu'en php, avec des conneries comme ça...et impossible d'utiliser la moitié des fonctionnalités d'un sgbd en y collant des horreurs de ce genre...

 
ba c clair que si tu ne met que l'objet, ya pas grand intérêt, maintenant si tu y rajoute certain champs bien choisi... pourquoi pas

bof, non.
Une bdd est là pour stocker des données, pas pour pourrir tes données avec des trucs spécifiques à ton appli, normalement.
A part pour une implémentation perso d'un système de sessions je classe ça dans la catégorie "design pourri".

... je classe ça dans le pourquoi pas, mais aussi dans le "pas chez moi "

bah pour que ce soit utilisable autrement que pour des sessions il faut dupliquer des données, voilà pourquoi pas.

pis là vu l'exemple, autant tout mettre dans une bdd et faire un fetch_object. Le résultat est identique et c'est autrement plus mieux

 
Exactement ! C'était là où je voulais en venir.
Je ne comprenais vraiment pas l'utilité de stocker un pareil objet en base si on ne peut pas faire de recherches...
 
Sinon, stocke un objet en base pour s'en reservir plus tard en tant que tel, pourquoi pas effectivement. Même si j'aurai préféré le stocker plutôt en Session.
 
En tous cas, merci à tous d'avoir donné votre avis !

La sérialisation n'est pas forcément utilisée pour stocker un objet en base de données.  
Elle peut être utile si par exemple tu fais du xml-rpc entre 2 applications php distantes.
Tu serialises l'objet.
Tu l'envoies encodé en xml via xml rpc.
L'autre coté reçoit l'objet en parsant le xml et en le désérialisant.
 
L'avantage évident est que cela évite de devoir extraire les données de l'objet d'un coté. De la même manière, cela évite de l'autre coté à devoir instancier un objet puis lui assigner les attributs récupérés via xml rpc.
 
Pour ceux qui ne savent pas ce qu'est XML RPC : http://fr.wikipedia.org/wiki/XML-RPC
 
Son petit frère le nouveau : http://fr.wikipedia.org/wiki/SOAP

euh soap c'est loin d'être nouveau.
et utiliser la sérialisation php pour ça, lolilol.
Le but du jeu c'est de pouvoir réutiliser le résultat dans un autre langage, à la base, hein...

SOAP et XML-RPC sont utilisable dans de très nombreux langages, il suffit d'implémenter les spécifications de leur API.
De plus, leurs API sont déjà implémenter dans de nombreux langages, et SOAP et XML-RPC étant orientés SOA il est évident qu'il sont réutilisables, c'est le but même de leur existence.
Libre à toi de faire ce que tu veux. Mais si tu réfutes constamment les explications qu'on te donne, c'est certain que tu auras du mal à avancer.

 
Tu es conscient que tu réponds complètement à coté de la plaque, quand même?
Quand on parle de sérialisation en php, c'est via serialize() et unserialize().
Qui n'utilisent absolument pas un format xml.
Et qui donc ne servent à rien dans le contexte de soap/xml-rpc.

'fin bref avant de vouloir me donner des explications commence par maitriser le sujet mieux que moi...

 
Dans osCommerce, ils font de la serialisation pour mémoriser ton panier, certes pas dans la base de données, mais dans un cookie. Ainsi, on peut placer un array serialisé dans le cookie, et le récupérer tel quel.
On déserialise le cookie et on a a nouveau le cookie. C'est pariculièrement interressant dans ce cas puisqu'un array de produits par ex est très facile à manipuler. Et puis de toute façon, je ne vois pas d'autre solution pour stocker ton panier dans un cookie sans serialiser/deserialiser. (Si tu fais implode, explode pour manipuler le contenu du cookie ça revient à le serialiser/deserialiser !)

Pour le moment, je crois que la seule fois où j'ai utilisé la sérialisation, c'était pour stocker un array dans une constante

On peut très bien imaginer une table cart_contents(id_user, id_cart, id_article), avec un cookie contenant `id_user`