ARTDEPARTMENT
ARTDEPARTMENT
En junio de 2005, el mundo del software era muy dispar: YouTube acababa de manar, PHP dominaba la web y MySQL era la opción de colchoneta de datos preferida de muchos desarrolladores por su velocidad y simplicidad. En ese mismo mes, se reportó un bug en este extremo software que, 20 abriles a posteriori, contra toda previsión, sigue sin solucionarse.
Hoy, esta anomalía no solo amenaza la integridad de los datos gestionados con MySQL, sino que igualmente se ha convertido en un símbolo del estancamiento tecnológico y de la desconfianza creciente cerca de este sistema de mandato de bases de datos... que sigue siendo el segundo más usado conjuntamente.
El bug en cuestión se tráfico de una vulnerabilidad llano (sólo un peldaño por debajo de la máxima categoría, 'crítica') relacionada con los 'triggers' o disparadores de la colchoneta de datos. Pero, ¿qué es un 'trigger'?
Pongámonos en situación: imagina que tienes una hoja de cálculo, y que cada vez que escribes poco en una celda, automáticamente se actualiza otra celda con un nuevo valencia. Eso es, en esencia, lo que hace un disparador en una colchoneta de datos.
Su función más popular es ayudar a amparar la coherencia y seguridad de la información: por ejemplo, si borras una cuenta de afortunado, un 'trigger' podría cerciorarse de que igualmente se borren sus publicaciones o su historial de navegación.
El popular bug #11472 provoca que los 'triggers' no se activen cuando la modificación de los datos ocurre de forma indirecta, a través de lo que se conoce como una secreto foránea (foreign key).
Las claves foráneas sirven para conectar dos tablas entre sí. Por ejemplo:
Si borras un cliente, puede configurarse el sistema para que automáticamente se borren todos sus pedidos. Esto se denomina 'exterminio en cascada'.
Pero aquí es donde el bug entra en ámbito: si hay un 'trigger' que debería ejecutarse cuando se sedimento un pedido (por ejemplo, para restar ese pedido del total de ingresos), no se activa si ese pedido no fue borrado directamente, sino como consecuencia indirecta de sobrevenir eliminado al cliente. Es aseverar, el 'trigger' equivocación en hacer su trabajo sin que nadie lo note.
Porque rompe un principio secreto de las bases de datos: la integridad de los datos. En otras palabras, podrías pensar que tu sistema está llevando correctamente un control de los datos cuando en sinceridad hay procesos importantes que nunca se ejecutan.
Este error puede hacer que tus estadísticas estén mal, que tus cálculos financieros sean incorrectos, o que pierdas datos esenciales. Y lo peor: no te darás cuenta, porque no se genera un error visible. El trigger, simplemente, no se da por aludido.
Cuando se denunció el problema hace ya dos décadas, el equipo de crecimiento de MySQL reconoció su existencia y prometió resolverlo en la inminente traducción 5.1. Sin requisa, esa decisión nunca llegó. La única 'respuesta' oficial fue incluir una nota en la documentación que admite que "las acciones en cascada de claves foráneas no activan triggers".
La frustración de la comunidad ha sido tangible: en 2015, en los comentarios oficiales del bug, un afortunado escribió:
"Acabamos de originarse a sufrir este problema al implementar 'triggers' sobre eliminaciones en cascada. Por gracia, se agradecería mucho que dieran una decisión".
Pero mucho más bisutero fue este otro comentario publicado en 2020:
"Este bug es más añoso que yo".
Aunque el bug fue reportado mucho antiguamente de que Oracle adquiriera MySQL en 2010, muchos ven su persistencia como refleja de un deserción sistemático del tesina. Incluso voces respetadas como la de Peter Zaitsev, cofundador de Percona y exingeniero de MySQL, han destacado a Oracle de "descuidar el rendimiento de MySQL" y reservar las innovaciones para su traducción en la estrato, Heatwave.
Algunos defensores de amparar el bug libre argumentan que cambiar el comportamiento ahora podría romper sistemas que, tras 20 abriles, han aprendido a residir con esta obstáculo. Pero en este caso, esa defensa resulta proporcionado débil: es poco probable que cierto dependa conscientemente de que un 'trigger' no se ejecute cuando debería.
Este bug ha sido la ápice que colmó el vaso para muchas empresas, para las que este bug ha sido la ápice que ha colmado el vaso y provocado su deserción de MySQL.
Según los rankings, MySQL sigue siendo el segundo sistema de bases de datos más utilizado del mundo, solo por detrás del software privativo Oracle, y todavía por delante de Microsoft SQL Server. Pero la tendencia es clara: su popularidad está en descenso, mientras que PostgreSQL asciende rápidamente.
Aunque estas métricas se basan en menciones y ofertas laborales más que en uso positivo, no dejan de ser un termómetro del percibir del ecosistema tecnológico.
Otro termómetro son los foros como Reddit, donde proliferan las recomendaciones de portar a PostgreSQL, y comentarios como "La decisión no es usar triggers de otra forma, es usar una colchoneta de datos relacional prudente".
De hecho, PostgreSQL se ha convertido en el refugio más popular para quienes huyen de MySQL. Su respeto riguroso por las reglas ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad) y su activa comunidad lo han posicionado como una alternativa fiable.
Las organizaciones que aún dependen de MySQL —especialmente si usan triggers como parte de sus políticas de integridad— deberían tomar cartas en el asunto:
Imagen | Marcos Merino mediante IA
En Genbeta | Las cuatro mejores plataformas infundado para practicar SQL, el jerigonza de bases de datos por excelencia
Compartir este artículo
Consultoria Personalizada
¡Si aun no tienes presencia en internet o
necesitas ayuda con tus proyectos, por favor, escribenos!
En ARTDEPARTMENT nos especializamos en brindar soluciones para que tu negocio, empresa o proyecto sea visible en internet.