Por no mencionar la ausencia de esfuerzo en refactorizar el modelo de datos para (des/re)normalizarlo según sea lo más apropiado.

En mi experiencia, lo ecléctico vence: tera-petabytes de datos en modelos simples van mejor distribuidos, cacheados y no relacionales.

Cantidades similares y sobre todo inferiores de datos, bien estructurads y modelizados las gestiono con SGBDRs.

Mismamente esta pasada semana hemos postergado unos meses generar desde un TPS el correspondiente datawarehouse para continuar soportando análisis dinámico y cuadro de mandos que ¡lleva 1 año tirando directamente del TPS sin colapsar el proceso on line diario! Pero claro, la refactorización del modelo de datos de ese TPS es trimestral…

Un saludo

Lo que pasa es que crear una birria de sistema de almacenamiento distribuido pre-relacional y pre-SGBD es infinitamente más fácil que crear un buen SGBD distribuido relacional.

Esto son solo productos de transición que en muchos aspectos son un enorme paso hacia atrás.

Todo el mundo sabe que no hay ninguna alternativa viable al Modelo Relacional y que probablemente nunca la haya.

También hay que separar el Modelo Relacional de las implementaciones que existen actualmente que son muy poco satisfactorias.

Un buen SGBD relacional tendría que optimizar bien hasta la consulta peor hecha, crear índices automáticamente en caso de necesidad y ajustar el modelo físico para que las consultas con multiples joins sean igual de rápidas que las consultas a una sola tabla.

Yo no me atrevería a afirmar con tanta rotundidad que la arquitectura de Facebook o servicios similares sea directamente un “birria”.
Es posible que Facebook pudiere correr igual, o mejor, en un SGBDR, y que por coste, tiempo, u otros factores lo implementaran en PHP contra MySQL y Cassandra con memcached a saco.
La cuestión en ese caso creo que es ¿Podrían haber implementado Facebook sobre una infraestructura Open Source de SGBDR que fuese para ellos asequible en costes?

Pues lo es sin duda, y que lo haga Facebook y similares es completamente irrelevante.

No es que sea posible que Facebook pudiese correr igual o mejor con un SGBDR, es que es una tautología. El rendimiento es siempre independiente del modelo lógico de datos.

Respecto a que haya sido una buena elección o no, pues es posible que sí lo haya sido. Si no encontraron un SGBD que les sirviese pues no les quedó más remedio que hacer una chapuza a pelo. O también es posible que lo hayan hecho así por ignorancia.

Para mi la cuestión es que el grupo nosql es un movimiento neo-ludita que quiere que volvamos a la oscura época pre-SGBD en lugar de que se mejoren los SGBD para que también sirvan para sitios como Facebook.

Suscribo tu último párrafo, Alfredo.

No estoy de acuerdo sin embargo con lo de que el rendimiento sea independiente del modelo lógico. Eso es sólo en teoría. En la práctica el modelo lógico elegido/diseñado implica una serie de dependencias del código, de la implementación del backend de datos, etc.

Eduardo, estamos de acuerdo en que eso es así en la teoría.

En la práctica el rendimiento sigue siendo independiente del modelo lógico, pero no lo es del modelo físico.

Lo que pasa es que con los SGBD de los que disponemos la independencia del modelo lógico con respecto al modelo físico está muy poco conseguida. Entonces por una pobre implementación el rendimiento depende indirectamente del modelo lógico.

Cuanta más flexibilidad tengamos en la definición de los modelos físicos más nos acercaremos en la práctica a la independencia de la que nos habla la teoría (y menos necesitaremos las primitivas herramientas de las que estamos hablando).

El problema es que se está trabajando muy poco para conseguir esto.

Concordamos, Alfredo. El mundo TIC está en muchos aspectos en una continua huida hacia adelante y una vez que se consolida una tecnología (la relacional, mismamente) hasta el punto de estar en producción establemente (y muchas tecnologías, especialmente en el mundo de la web 2.0, a veces ni eso) ya se paran los esfuerzos en la consolidación y profundización de las bases de la tecnología y continuan en las features más absurdas que cualquiera proponga o abandere. Fuegos artificiales.

Si Oracle, un poner, hubiese dejado de invertir esfuerzos en grid y toda esa parafernalia, en atajos para dar rendimiento con pobres diseños del modelo lógico y se hubiese dedicado por ejemplo a profundizar en técnicas heurísticas de optimización de consultas complejas, en modularización del gestor para poder generar versiones ligeras para competir (en consumo y rendimiento, no hablo de mercado) con mysql y similares, en contribuir a la estandarización oficial de extensiones procedimentales abiertas del SQL porque tuvo una posición de privilegio para hacerlo, etc etc otro gallo nos cantaría y la base de facebook a lo mejor estaría sobre oracle pero lo más importante, el modelo relacional habría avanzado para ser la una base tecnológica más amplia aún.

Oracle hace tiempo que ha dejado de ser una empresa de desarrollo de software. Ahora sólo son una gigantesca maquinaria financiera de engullir y asimilar otras empresas al estilo Borg.

“le está metiendo unos zambombazos al SGBDR del calibre de un pepino nuclear, sobre todo en forma de joins múltiples, búsquedas por campos sin indexar, y exceso de tráfico de datos entre el cliente y el servidor”.

… y a veces, a fuerza de darse contra la pared, terminamos aprendiendo que hay que pensar dos veces antes de hacer CUALQUIER COSA con SQL.

Ahora, si a los mismos monos con navaja que hacen delirios en sql les das un soporte de almacenamiento en el que no hay ninguna regla más que clave=valor y que encima NUNCA te va a obligar a optimizar nada porque no tiene problemas de performance…. yo no quiero hacer mantenimiento de esos sitemas.

Las bases de datos relacionales tienen un efecto colateral en el código, y es que hacen que éste, en general, sea un poco más prolijo, justamente pq hay que encapsular llamadas a store procedures, hacer una capa de acceso a datos, tener el sql separado para poder optimizarlo, etc. etc. etc. (esto no es SIEMPRE así, recalco, hablo “en promedio”).

No van a “matar a las bases de datos relacionales” por el simple hecho de que éstas tienen su ámbito de aplicación y las no relacionales el suyo propio, y si bien hay un espacio en el que se puede dudar entre una y otra tecnología, en el 99% de los casos es bastante claro lo que corresponde.

Eso de encapsular llamadas a procedimientos almacenados y crear una capa de acceso a datos no tiene porque ser así. El promedio es que la mayoría de la gente no tiene mucha idea de como usar bien un SGBD SQL.

Las bases de datos relacionales tienen un ámbito muy grande, pero los productos concretos como Oracle o SQL Server tienen un ámbito bastante más reducido. No hay que confundir el Modelo Relacional con lo que implementan Oracle o Microsoft. Es más, estrictamente hablando ni el lenguaje SQL ni SQL Server ni Oracle son relacionales sino solo un sucedaneo.

Por cierto, he leido por ahí que Facebook sigue usando fundamentalmente MySQL y que eso de Cassandra lo usa solo para cosas muy puntuales.

Si le prestas una excavadora a alguien, puede acabar matando a unas cuantas personas. Eso no implica que las excavadoras sean intrínsecamente inseguras, sino que su peligrosidad depende de quien las maneje. Y SQL es una excavadora muy grande.

Pero tienes el mecanismo de seguridad del SGBD para recortar todo lo que quieras las posibilidades de los usuarios.

Lo malo es que hay muy poca gente que sepa usar esas cosas.

Si una base de datos está bien configurada te debería de dar igual si el usuario entra con una aplicación o con una consola SQL.

Ya, bueno, pero lo de las limitaciones a los zambombazos es en teoría, porque ¿cuantas veces se ha visto una aplicación que lo primero que hace al abrir la pantalla inicial es SELECT * FROM EMPLEADOS? Y cuanto pones a optimizarla, simplemente quitas esa consulta que no sirve para nada y se está lanzando chopocientas mil veces, y mejoras el rendimiento de un plumazo.
Lo bueno de tener un API que funciona como un mapa asociativo que sólo puede recuperar un único valor dada una clave es que obligas al programador a pensar mucho más si realmente necesita recuperar un porrón de datos de golpe o se podría apañar con menos.

Ah, te referías a eso.

Ya, hay muchas aplicaciones que hacen un uso poco eficiente el SGBD, y muchas herramientas de programación que te ocultan complejidad pero también son muy ineficientes. Yo me he llevado muchas sorpresas con el depurador viendo como eventos que tienen que leer de la base de datos saltan varias veces seguidas sin motivo.

Pero eso se soluciona examinando el log de las consultas a la base de datos y preguntandole al programador el por que de los zambombazos.

Lo del SELECT * FROM EMPLEADOS se soluciona haciendo paginación. Eliminar la consulta está bien en una aplicación Web, pero en una de escritorio es muy cutre.

Yo veo que hay muchas aplicaciones que están diseñadas para que el programador se complique la vida lo menos posible en lugar de para ser utilizadas cómodamente. Lo que hay que pensar es si el usuario necesita que se recuperen un porrón de datos de golpe.

Lo de una API que solo puede recuperar un único valor dada una clave es trogodítico total.

Me paso la vida revisando código y echando broncas de por que se hacen las select de tal o cual forma en pl/sql, jsps o clases.

Cuando veo subselects o uniones siempre digo sin pensar “está mal”, desgraciadamente suelo acertar en un 99%.

Si se hacen chapuzas o se trabajan en lenguajes que no se domina, dará problemas sea cual sea el sistema que utilices.

Una consulta está mal cuando no devuelve los resultados esperados.

Si el optimizador no es muy bueno y hace falta escribir las consultas de una forma determinada para que sean más rápidas, es sobre todo un problema del producto. Se supone que el optimizador está para que solo tengamos que preocuparnos de que las consultas sean correctas y no óptimas para un SGBD en particular.