Je travaille sur un petit projet perso et j'ai commis l'erreur classique de tout mettre dans une seule table SQL. Maintenant, à chaque fois que je dois ajouter un champ pour une nouvelle fonctionnalité, je me retrouve à devoir gérer des colonnes vides pour la moitié des lignes, et ça devient vraiment désordonné. Je me demande si je n'aurais pas dû réfléchir à une normalisation dès le début, quitte à avoir plus de tables à joindre. Certains d'entre vous ont-ils déjà été dans cette situation sur un projet qui a grandi petit à petit ? J'hésite à tout refactoriser maintenant ou à continuer comme ça en me disant que c'est trop tard.
|
Quoi faire face à une base SQL qui grandit sans tout casser ?
|
|
Ta intuition est bonne: la normalisation est exactement ce qu’il faut quand les colonnes commencent à devenir trop hétéroclites. En grandissant, une base normalisée te permet d’ajouter des attributs sans toucher à la structure existante, en utilisant des tables liées et des clés étrangères. Le coût réel ce sont les jointures et les migrations, mais c’est un investissement qui peut payer sur le long terme. Le mot clé ici est normalisation et penser en termes d’entités et d’attributs plutôt que de colonnes isolées.
J’ai vécu ce dilemme: refactoriser tout d’un coup ou continuer comme ça jusqu’au prochain bug. Je penche pour une approche par paliers: identifier les attributs qui varient, créer une table d’attributs et une table d’associations, puis migrer par lots. La normalisation aide à réduire les NULL et les colonnes vides, mais cela rend les requêtes un peu plus complexes à écrire au début.
Et si le vrai problème n’était pas d’opter pour ou contre la refactorisation, mais la manière dont on gère les évolutions? La normalisation peut aider, mais elle ne règle pas tout si le backlog de fonctionnalités s’accumule ou si les choix d’architecture ne sont pas clarifiés. Peut-être qu’on gagnerait à clarifier les entités et leurs cycles de vie plutôt que d’essayer d’emboîter tout dans une seule vue.
|
|
« Sujet précédent | Sujet suivant »
|

