Résistez au démon de la sérialisation et structurez vos données dans vos bases: meilleures performances, souplesse et légèreté du code, maintenance facilité.

J’ai déjà entendu un développeur dire fièrement “Moi, j’ai une super structure de données: j’ai mes objets (PHP) que je sérialise, puis je les sauve dans une table et dans une autre, j’enregistre les relations entre ces objets. Ma BDD tiens en 2 tables, et je peux y mettre tout ce que je veux!”. Cette approche n’est pas une bonne utilisation d’un SGBD: vous devrez faire plus de code vous-même pour moins de perfs.

L’absence de structure

Cette approche consistant à tout sérialiser avant de mettre les données en base n’a pas besoin de beaucoup de tables: vous pouvez directement stocker tout… et n’importe quoi. Et c’est bien là le problème: si l’absence de structure permet de stocker tout facilement, cela ne permet pas de bénéficier de toute la puissance de , et encore moins de manipuler ces données.

Comparaison

Sérialisation

Avec la sérialisation, si vous souhaitez manipuler un objet, vous allez devoir le récupérer (via son id), puis le désérialiser, le traiter, le sérialiser, et le remettre dans la base. Ces opérations sont longues, mais surtout, vous ne pourrez pas manipuler les données sans devoir les sortir du SGBD, et cette sortie se fait toujours ligne par ligne. En conséquence, votre serveur va ramer.

Structure usuelle

Si vous structurez vos données, par exemple avec une table par “classe” pour stocker vos données proprement, alors vous passerez un peu plus de temps à créer votre structure de BDD (genre 2 minutes), mais vous gagnerez énormément en terme de performances (vous pourrez user des

JOIN
et
WHERE
) et de lisibilité (vous remplacerez des tartines de PHP par une simple requête SQL).

Conséquences de la sérialisation

Intégrité des données

L’approche de sérialisation va également vous empêcher de bénéficier des garanties d’intégrité du SGBD: plages de validité des valeurs, les clés étrangères, ou les conditions d’unicité ne pourront pas être vérifiées par le SGBD (dont le code n’est pas à votre charge!) et devront être vérifiées dans vos propres codes PHP.

Solidité dans le temps…

Les données sérialisées stockent en même temps les données d’un objet et sa structure: vous allez au devant de grosses difficultés quand vous mettrez vos classes PHP à jour, car vos nouvelles classes deviendront incompatibles avec leurs anciennes versions sérialisées. Votre code va finalement se rigidifier (alors que vous pensiez l’assouplir en virant la structure du SGBD), et votre belle idée de “je peux stocker n’importe quoi facilement” va vite devenir “je ne peux plus rien toucher à ce que j’ai sauvegardé”.