Concevoir un modèle de données qui tient des années
Commencer par les entités
Quelles sont les choses dans le monde — client, commande, article, paiement — et les relations entre elles. Des noms qui correspondent au langage de l'équipe commerciale économisent d'innombrables malentendus.
N'aplatissez pas les relations plusieurs-à-plusieurs en champs texte. « Des tags séparés par des virgules » est une dette payée douloureusement la première fois qu'on doit filtrer dessus.
Distinguer un fait d'un état
Un état actuel change. Un fait — s'est produit. Une commande a un état ; un paiement est un événement qui s'est produit. Les systèmes qui perdent l'historique ne peuvent pas répondre à des questions basiques comme « quel était le prix ce jour-là ».
Donc : conservez des enregistrements d'événements à côté des enregistrements d'état, surtout pour tout ce qui touche l'argent et les autorisations.
Des champs qui valent toujours la peine
Heure de création et de mise à jour, qui l'a effectué, une version ou un cachet pour détecter les conflits, et une suppression douce plutôt que dure là où une récupération pourrait être nécessaire.
Pour aller plus loin
Quand un modèle doit changer, préférez l'ajout à la suppression, et exécutez le changement comme une migration par étapes. Et documentez les décisions de modèle brièvement — pourquoi il y a deux tables et non une — car dans un an personne ne s'en souviendra, et la tentation de simplifier quelque chose de délibéré est grande.