Estoy relativamente recién salido de la universidad, por lo que la mayor parte de mi familiaridad con las bases de datos relacionales proviene de mi curso de bases de datos, donde cualquier cosa que no esté en BCNF o 3NF es una parodia. Ciertamente, ese es un extremo del extremo, pero mi equipo en el trabajo realmente parece llevarlo al extremo opuesto.
En nuestros esquemas de microservicio db, las entidades rara vez tienen más de una tabla. Todo lo que normalmente normalizaría en otra tabla se almacena en una columna json. Si luego se descubre que es necesario consultar una de las propiedades de este json, se agrega una nueva columna y los datos se almacenan en ambos lugares (sí, en dos columnas diferentes en la misma tabla).
En muchos casos, estas columnas json definitivamente tienen una ventaja. Si nunca necesita consultar esos datos y si nunca tiene que hacer un cambio unilateral a esos datos (que es algo que obviamente no puede predecir), no es una mala idea. Además, muchos de nuestros servicios no ven el servidor o están alojados en máquinas con una cantidad obscena de espacio en disco para lo que necesitan, por lo que la duplicación de datos no es un gran problema. (Aunque es algo que generalmente me gustaría evitar por filosofía)
Actualmente estamos creando un servicio que coincide con las reglas en función de un conjunto de condiciones que poseen y luego realiza un conjunto de acciones asociadas con esas reglas cuando las reglas son verdaderas (por ejemplo, todas las condiciones son verdaderas). Mi sub equipo que está construyendo este servicio de manera más inmediata cree que hay un beneficio sustancial en la normalización de acciones y condiciones fuera de las reglas del esquema. Obviamente, esta tabla mantiene relaciones de clave externa con el ID de la regla. Desde nuestra perspectiva, podemos evitar la duplicación de datos en condiciones que nos permiten asegurarnos de que solo se evalúen una vez y es fácil encontrar las condiciones y reglas que necesitamos cuando las necesitamos sin necesidad de extraer cada regla y realizar la búsqueda en la memoria.
Al hablar hoy con uno de nuestros ingenieros principales, intentó alejarme de este esquema. Intentar argumentar de todas las formas que realmente no lo necesitamos va a causar problemas de rendimiento en el futuro, haciendo referencia a un viejo monolito que poseemos que es una parodia del diseño. Se refirió a lo que estamos haciendo como "la vieja forma" y las mesas planas con json como "la nueva forma". Argumentó que en lugares donde quiero atomicidad no la necesitamos y que en lugar de consultas deberíamos hacer más cosas en la memoria. Este es un principio de diseño que muchos de nuestros servicios siguen ahora. No anticipamos que el volumen de nuestros datos crecerá sustancialmente, lo que debería mantener nuestras consultas rápidas. Lo que anticipamos es mucho tiempo dedicado a la evaluación de reglas y a la realización de acciones.
Entiendo que las bases de datos no relacionales se han vuelto más populares en los últimos años, pero incluso cuando busco activamente información sobre las implicaciones de rendimiento de las relaciones de claves externas, no veo mucha información que haga su caso. Supongo que podrían tender a introducir grandes transacciones que pueden causar problemas, pero eso parece un problema independiente de la clave externa en sí.
¿Es esta mi ingenuidad? ¿O es esto realmente algo que yo y mi sub-equipo nos falta? No he dado explícitamente información detallada sobre nuestro problema porque no estoy necesariamente buscando una solución para eso. Dado que es una tendencia común en nuestro equipo más grande, tengo mucha curiosidad si tienen algo con esto.