Je suis relativement fraîchement sorti de l'université, donc la plupart de mes connaissances avec les bases de données relationnelles proviennent de mon cours sur les bases de données où tout ce qui n'est pas en BCNF ou 3NF est une parodie. C'est certainement une extrémité de l'extrême, mais mon équipe au travail semble vraiment aller jusqu'au bout.
Dans nos schémas de base de données de microservices, les entités ont rarement plus d'une seule table. Tout ce que vous normalisez généralement dans une autre table est stocké dans une colonne json. S'il est découvert plus tard qu'une des propriétés de ce json doit être interrogée, une nouvelle colonne est ajoutée et les données sont stockées aux deux endroits (oui, dans deux colonnes différentes dans la même table).
Dans de nombreux cas, ces colonnes json ont certainement un avantage. Si vous n'avez jamais besoin d'interroger ces données et si vous n'avez jamais à apporter de modifications unilatérales à ces données (ce que vous ne pouvez évidemment pas prédire), ce n'est pas une mauvaise idée. De plus, beaucoup de nos services ne voient pas de serveur ou sont hébergés sur des machines avec une quantité d'espace disque obscène pour ce dont ils avaient besoin, donc la duplication des données n'est pas un problème majeur. (Bien que j'aimerais généralement éviter la philosophie)
Actuellement, nous construisons un service qui correspond aux règles en fonction d'un ensemble de conditions dont ils sont propriétaires, puis exécute un ensemble d'actions associé à ces règles lorsque les règles sont vraies (par exemple, toutes les conditions sont vraies). Mon équipe secondaire qui construit le plus immédiatement ce service pense qu'il y a un avantage substantiel à normaliser les actions et les conditions loin des règles du schéma. De toute évidence, ces tables conservent des relations de clé étrangère avec l'ID de règle. De notre point de vue, nous pouvons éviter la duplication des données sur les conditions, ce qui nous permet de garantir qu'elles ne sont évaluées qu'une seule fois et il est facile de trouver les conditions et les règles dont nous avons besoin en cas de besoin sans avoir à extraire chaque règle et à effectuer la recherche en mémoire.
Aujourd'hui, en discutant avec l'un de nos principaux ingénieurs, il a tenté de m'éloigner de ce schéma. Essayer de faire valoir de toutes les manières que nous n'en avons pas réellement besoin va causer des problèmes de performances à l'avenir, en faisant référence à un vieux monolithe que nous possédons qui est une parodie de conception. Il a fait référence à ce que nous faisons comme «à l'ancienne» et aux tables plates avec json comme «à la nouvelle façon». Il a soutenu que dans les endroits où je veux l'atomicité, nous n'en avons pas besoin et qu'au lieu de requêtes, nous devrions faire plus de choses en mémoire. Il s'agit d'un principe de conception que nombre de nos services appliquent actuellement. Nous ne prévoyons pas que le volume de nos données augmentera considérablement, ce qui devrait permettre de garder nos requêtes rapides. Ce que nous prévoyons, c'est beaucoup de temps consacré à l'évaluation des règles et à l'exécution des actions.
Je comprends que les bases de données non relationnelles sont devenues plus populaires ces dernières années, mais même lorsque je recherche activement des informations sur les implications des relations avec les clés étrangères en termes de performances, je ne vois pas beaucoup d'informations pour le défendre. Je suppose qu'ils pourraient avoir tendance à introduire des transactions importantes qui peuvent causer des problèmes, mais cela semble être un problème indépendant de la clé étrangère elle-même.
Est-ce ma naïveté? Ou est-ce vraiment quelque chose qui manque à ma sous-équipe et moi? Je n'ai explicitement pas donné d'informations détaillées sur notre problème car je ne cherche pas nécessairement une solution à cela. Étant donné que c'est une tendance commune dans notre grande équipe, je suis vraiment curieux de savoir s'ils sont sur quelque chose avec ça.