Comencemos aclarando que con SQL nos referimos al modelo de desarrollo relacional y con NoSQL a los desarrollos no relacionales. Con ese antecedente, presentamos el escenario actual, donde en los últimos años NoSQL ha resultado ser una tendencia al alza y cada días más y más desarrolladores centran sus esfuerzos en migrar los sistemas relacionales hacia este modelo. Ahora: ¿siempre es útil desarrollar con NoSQL por sobre modelos relacionales? ¿NoSQL es la solución a todos los desarrollos? ¿SQL está obsoleto?
El modelo relacional es el modelo estándar y el más utilizado a nivel global, pero tiene el problema de que a pesar de ser muy robusto, es muy poco flexible. Este modelo está compuesto por una base de datos que a su vez tiene tablas con columnas estructuradas. Al llevar más tiempo en el mercado, el soporte y herramientas disponibles para trabajar con este modelo es bastante amplio. Además, el modelo permite transaccionalidad entre tablas, al no comprometer datos existentes en caso de que exista un error en alguna transacción que se ejecute sobre la base de datos. Sin embargo, el modelo es muy poco flexible, ya que exige que todos los datos estén validados contra la definición de cada campo. Junto con esto, debido a la atomicidad de los elementos, mientras más compleja se hace la estructura de una base de datos, más procesamiento se necesita y también es muy poco escalable (definitivamente el mayor inconveniente y que permitió el desarrollo de NoSQL), puesto que la inversión en hardware generalmente resulta ser muy costosa a la hora de conjugar crecimiento y rendimiento. Ahora, el modelo NoSQL está muy de moda entre los desarrolladores "modernos", debido a que -lamentablemente- no requiere un acabado conocimiento académico sobre teorías de sistemas de gestión de bases de datos ni de álgebra relacional y por esto, su curva de aprendizaje es bastante rápida. A diferencia del modelo relacional, acá en buena parte de los casos existen bases de datos sin una o más tablas fijas, compuestas de colecciones y a su vez de documentos. Cualquier servidor con recursos mínimos será capaz de ejecutar un sistema NoSQL. Esto, sumado al hecho de ser bases de datos no estructuradas lo transforman en una herramienta muy útil en el tratamiento de Big Data. Acá, el problema es la poca estandarización de los distintos sistemas NoSQL (lo que limita el número de aplicaciones seguras para realizar transacciones) y más complejo aún, la poca integridad sobre las transacciones. Muchos jefes de TI, gerentes de sistemas y desarrolladores piensan que NoSQL al ser "lo nuevo" debe transformarse en el estándar de desarrollo y por lo tanto centran sus esfuerzos en migrar hacia ese modelo. Razonamiento errado, puesto que lo que debe primar siempre es la necesidad detrás de cada desarrollo. ¿En el proyecto es necesaria integridad referencial en los datos? ¿Se necesitan identificar patrones? ¿O acaso el proyecto contempla miles o millones de sensores que solo recogen y transportan información hacia una base de datos central? Antes de migrar o forzar el desarrollo de un proyecto utilizando una u otra tecnología porque "está de moda", es necesario conocer las diferencias entre ambos tipos de bases de datos y conocer muy bien el proyecto y la finalidad de este, junto con comprender las arquitecturas de ambos modelos. Para decidir “el dilema”, se debe analizar el proyecto sobre el que estoy trabajando, lo que se quiere conseguir, el tipo de datos que se utilizarán y todos los otros factores asociados, como costos versus recursos, capital humano, etc. Solo con dicho escenario claro es posible definir si, en esta oportunidad, es conveniente utilizar SQL o NoSQL… y resolver el dilema.
Comments