Practmcamente me lleve todo el dia de hoy revisando codigo del segundo monolito qu corre bajo laravel 5.3 y php 5.6. El problema es una serie de asuntos, empezando que Laravel funciona bajo un esquema mixto de estandares no relcionados, que esto parece ser Laravel solo de nombre, y que correr la prueba de un STORE procedure de su base de datos, corre 4 veces mas rapido en mi server secundario que en aquel que el cliente tiene su información.

Hace unos años tuve que ver un problema de laravel 4 a 5 donde perdieron datos, y todo resultó que el cambio de esquema provocó en una de las «migraciones» como se le llama actualización de base de datos en Laravel, a perder el contenido de las mismas. Y aunque los framewoks no son santo de mi devoción, aqui me encontre ademas la novedad de store procedures, functions, shedulers que hacen que el respaldo no pueda automatizarse la subida, y todo para cosas que debieron hacerse en el mismo código. Para acabarla estamos hablando de un universo masivo de 12 gb de pdf, sobre una base de datos de 100mb.

va a haber mucho trabajo esta semana, pero es ridiculo que los store procedures se usen para calcular el estado de terminado de un objeto, y que no se corran a voluntad, cuando pudo hacerse con indices correctos. No habia comentado también que NO tenía Foreign keys asi que no hay integridad referencial y probablemente tampoco catálogos de altas bajas cambios con CRUD. Es algo sencillo y descuidado, que parece ser de un buen estudiante de 2016. Pero solo eso. Y parámetros GET en cantidades industriales. A mi me preocupa especialmente que mover de laravel a versiones mas modernas implica cambiar la versión de php a mysqli, pero el problema de rendimiento era incluso sobre 7.4.3 de php.

En resumen, mañana me toca bucear en las tablas de la base de datos. No se ve buena idea que hayan problemas para cargar sus propios respaldos como admin del server por la presencia de procedures que debieron estar en código y uno de ellos debió de ser vista, no procedure.