La cuestin gira en torno a la decisin de si debe o no abrazar bases de datos SQL - el enfoque

tradicional - o bases de datos NoSQL favorecida por aquellos que abrazan la nube. Diferentes empresas
requieren diferentes enfoques en funcin de sus necesidades, pero al menos un miembro del jurado no
fue tmido a la hora de compartir sus puntos de vista.

"SQL es terrible", dijo Cliff Luna, director de tecnologa de Fronteras. "Es muy malo." La compaa de la
luna hace que las herramientas de monitorizacin de aplicaciones a travs de la red, en lugar de
servidores o dispositivos de almacenamiento a travs de, lo que significa que est interesado de forma
natural en un modelo de base de datos ms flexible.

Pero la flexibilidad no significa necesariamente que para la estabilidad. "Me gustara que mi cuenta
corriente para funcionar en Mongo?" Pregunt David Rubin, director de desarrollo de base de datos
NoSQL de Oracle. "Les puedo decir con seguridad que la respuesta es no."

Barry Morris, CEO de NUODB, quiere dividir la diferencia. Su compaa est trabajando en productos
que "mantienen capacidades completas de bases de datos relacionales, pero con grandes bases de
datos escalables." Eso permite la compatibilidad con las aplicaciones basadas en SQL mayores, pero en
un paquete ms flexible.
Es una decisin clave que los desarrolladores de aplicaciones tienen que hacer en el lanzamiento de un
producto, dijo Peter Van Handerburg, co-fundador de Heroku Postgres. "El cuidado y la alimentacin de
una base de datos es un trabajo a tiempo completo, a veces muchos puestos de trabajo de tiempo
completo", dijo. "Cuando los datos se pone muy grande, comienza a desmoronarse."

Articulo 2
Durante los ltimos 40 y tantos aos, las bases de datos relacionales han gobernado el mundo de los
datos. Modelos relacionales aparecieron por primera vez en la dcada de 1970 los primeros gracias a la
investigacin de los pioneros de la informtica tales como EF Codd. Las primeras versiones de lenguajes
de SQL como tambin se desarrollaron en la dcada de los 70, con SQL moderno aparece a finales de la
dcada de 1970, y cada vez ms popular a mediados de la dcada de 1980.

Durante el ltimo par de aos, los Internets se han llenado con acaloradas discusiones respecto a SQL vs
NoSQL. Pero es la lucha incluso legtimo? Bases de datos NoSQL han crecido un poco (y algunos, como
BigTable de Google, estn ahora maduros) y demostrar que son dignos. Y sin embargo, la lucha
contina.

Antes de continuar, sin embargo, quiero hacer una aclaracin. En este artculo, estoy usando el trmino
"SQL" poco rigor. Tcnicamente hablando, SQL es el lenguaje utilizado para acceder a una base de datos
relacional. Puede utilizar otros idiomas o tcnicas para acceder a los datos. Cuando la gente discute "SQL
vs NoSQL," en realidad estn hablando de bases de datos relacional frente no relacionales. Eso es lo que
estoy hablando aqu: bases de datos relacionales (como Oracle, MySQL y SQL Server) frente a las bases
de datos no relacionales ms nuevos (como MongoDB, CouchDB, BigTable, y otros).

Ahora, de vuelta a la lucha. Me paso mucho tiempo leyendo sobre ella, y me he dado cuenta de que,
mientras que la mayora de las personas simplemente discutir los mritos y las diferencias de lo
relacional frente bases de datos no relacionales, un pequeo porcentaje de las personas siguen siendo
extremadamente vocal-y incluso enojado con su apoyo firme para la una sobre la otra. A menudo, esos
defensores ms elocuentes son los administradores de bases.
Pero qu pasa con los programadores, que escriben el cdigo de cliente que accede a las bases de
datos? De dnde salen ellos los desacuerdos? Desde la perspectiva de la programacin, es SQL
realmente tan horrible y anticuado? O es la nueva NoSQL realmente horrible que trabajar? Tal vez
ambos tienen puntos fuertes y puntos buenos.

As que me gustara tomar el desacuerdo en una direccin diferente: Vamos a estudiar el problema en el
nivel de codificacin. Vamos a ver en realidad un par de idiomas y la forma en que trabajan con las
diferentes bases de datos y ver si podemos sacar algunas conclusiones. Nuestro espacio es limitado
aqu, as que al final voy a ofrecer nuevas ideas sobre donde se puede continuar con la exploracin.
Los viejos argumentos
Antes de zambullirse en el cdigo, quiero enumerar algunos de los argumentos ms comunes que he
visto.
En primer lugar, he aqu algunos argumentos en contra de las bases de datos relacionales, los
argumentos anti-SQL. Ahora entiendo por favor, yo no estoy diciendo que estos son necesariamente
precisa de slo que estos son argumentos que otros han hecho y que estoy compartiendo aqu para que
podamos mirar en ellos:
Las uniones en las bases de datos relacionales puede ralentizar el sistema a un arrastre, sobre todo
cuando millones de usuarios estn haciendo bsquedas en tablas con millones de filas de datos. Google
y Amazon han encontrado que este es el caso, y por lo tanto desarrollaron sus propios sistemas no
relacionales.

Datos relacionales no se correlaciona bien con las estructuras de programacin tpicos que a menudo
consisten en tipos de datos complejos o datos jerrquicos. Los datos como XML es especialmente difcil
debido a su naturaleza jerrquica. Objetos complejos que contienen objetos y listas dentro de ellos no
siempre se asignan directamente a una nica fila en una sola tabla.

Datos relacionales no se correlaciona bien. Combine eso con la necesidad de manejar la sintaxis de SQL,
y escribir cdigo de cliente para acceder a bases de datos SQL se vuelve difcil.
Son estos vlida? Si le preguntas a los proponentes de SQL, usted conseguir algunas buenas
respuestas acerca de por qu no lo son. Por ejemplo, Oracle es muy potente y puede optimizar une y
almacenar en cach ellos. Enormes bancos que sirven a miles de ramas y millones de clientes, entre
ellos cientos de miles de miembros en lnea, sobreviven muy bien el uso de SQL. As que aqu estn
algunos de los argumentos que he visto para SQL en respuesta a los tres grandes argumentos en contra
de SQL:

Usted no es tan grande un Google y usted no est buscando tantos datos como Google. (Este es uno de
los argumentos ms comunes, y probablemente tiene mrito.) Adems, los sistemas relacionales de hoy
en da, tales como Oracle son extremadamente potente y maduro y puede manejar uniones a nivel de
rendimiento que la mayora de los sistemas requieren. Esto no es de Oracle de su pap.