Tengo un trauma con SQL.
Un trauma profundo, con raíces que van más allá de la conocida canción y ahondan en la nula inmutabilidad de los datos o las insuficientes y casi inservibles backups. Me explico. Durante dos años estuve trabajando en una empresa en la que tuvimos que construir todo desde cero. Desde la infraestructura en la nube hasta cuentas de Microsoft para vendedores, desarrolladores y en general todo el staff. Durante los primeros meses profundicé en los fundamentos de creación de una infraestructura en cloud tratando preguntas como "¿Es mejor un entorno con AppServices o una infraestructura híbrida con clusters y Kubernetes?" o "¿qué pasa si hay cae un meteorito y una región entera de Azure deja de funcionar?". Preguntas, literalmente, de pausa para el café.
El problema es cuando empiezas a darte cuenta de que todo tiene que estar replicado, por dos, tres o cuatro, que necesitas tener una resiliencia a los fallos casi absoluta, empiezas a pensar en tener despliegues en los 3 major providers de internet (con AWS, GCloud y Azure) por si fallase el proveedor principal y, al día siguiente, haces un UPSERT a mano de treinta mil filas en producción que has editado a mano con tus habilidades de Sublime Text y el editor con cursor múltiple.
Muchos diréis been there done that, pero la diferencia entre el mundo ideal y el mundo real era tan abismal que al principio me daba pánico. Recuerdo desde eso hasta hacer ingeniería inversa a un software propietario solo para ver qué bug tenía y no tener que acudir a soporte y pagar más. Esperar 16h despierto para terminar una migración de un servicio on premises a cloud que venía en un HDD por mensajería urgente. También escribir, como decía, scripts de SQL de decenas de miles de líneas que mi pobre Mac apenas podía procesar. Le daba a "Select all ocurrences" (Command + Ctrl + G en Mac) al principio de la primera linea y esa selección podía tardar unos 30s. Luego, cada edición, desplazamiento o deleción eran otros 30s. Trabajando con datos masivos a mano. Era increíblemente peligroso, e increíblemente adictivo.
Una vez le perdí el miedo a aquella metodología de trabajo, realizar upserts a mano se convierte en tu día a día. Los datos estaban regu y había que hacer muchísimas operaciones a mano que hasta aquel momento realizaba el antiguo departamento de IT que se componía de un solo informático que se había dedicado a hacer aquellas tareas durante todos esos años. Cuando algo salía mal, salía muy muy mal. Una inserción mal: facturas generándose con número aleatorios. Por ejemplo, para reconciliar los datos teníamos que mantener las ids anteriores para poder movernos entre números de facturas erróneos y poder hacer una auditoría a posteriori para Hacienda. Había tablas con 4 ids repetidos que empezaban a ser todos iguales y de repente había saltos, porque, claro, las plataformas estaban hechas en terrible spaghetti code en PHP que no había quién manejara o viera cómo las operaciones concurrentes funcionaban y se saltaban IDs porque, claro, no había ni PKs o FKs en la DB. Había tensión en cada operación por ver si todo acabaría bien.
Cuando empezamos a desarrollar código nuevo tomando como base el código existente, muchas cosas no terminaban de funcionar bien. Había que ir rápido y no había tiempo para requisitos, funcionalidades o testing. Simplemente code fast deploy faster y que sea lo que NaN quiera. Todo aquello solo hizo que hubiese que tratar muchos datos erróneos en muy poco tiempo y asegurarnos de que no se estaba liando más la cosa. Teníamos controles manuales con un innumerable repositorio de cláusulas SQL que revisaban si todo estaba ok o no y que había que ejecutar a mano e ir ampliando y mejorando.
A los pocos meses desarrollé una forma de trabajo más adaptada a este mundo. Me cambié a Windows con BOOTCAMP y me instalé HeidiSQL que tenía decenas de funcionalidades para hacer magia negra. Cada vez que había que arreglar algo que no estaba bien en una bases de datos de producción, me guardaba una copia de seguridad de producción, digamos db_prod_20181123, la desplegaba de nuevo a mano (de verdad, gracias por tanto Heidi SQL) y trabajaba con esos datos, intentando ver cómo resolver el problema existente. A veces tocaba hacerlo con SQL Server, así que me tocaba trabajar con SQL Server Management Studio y hacer un poco de lo mismo. Tras el despliegue, la copia de seguridad no servía para nada, pero yo tenía que mantenerla por si pasase algo. De hecho, cuando aplicaba los cambios que había probado en la nueva DB réplica realizaba otra copia de seguridad antes de ejecutar las cláusulas SQL, digamos, db_prod_20181123_1453, y cruzaba los dedos para que no la tuviese que restaurar en lugar de la db_prod y volver a ver cómo resolver el problema de otra manera.
Cuando todo aquello se acabó, volví a la calma de "los datos no se tocan", y así he seguido hasta ahora. Toda esta historia ni tiene que ver con que esté volviendo a hacer UPSERT de decenas de miles de lineas en una db en prod, sino que me está tocando construir algunas piezas de una migración con Entity Framework a mano. Aunque no sea lo mismo, ha resucitado los fantasmas de trabajar en el data chaos. Durante aquella época aprendí a manejar muy bien los UPSERT, cursores múltiples, Sublime Text, Heidi SQL, SSMS y en general desarrollé una navaja suiza para el caos que espero no tener que utilizar nunca. Aun algún compañero, cuando comparto pantalla y edito con VS Code me pregunta "oye, un día nos tienes que enseñar cómo manejas tan bien los cursores múltiples". En ese momento miro al vacío durante unos segundos y recuerdos los gritos, las bombas, el vietcong sobre nosotros, el napalm y ahogo un grito de desesperación en un Sure, whatever.
Photo by Peter Herrmann on Unsplash