¿Por qué se ignoran las características de la base de datos y, en cambio, se reinventan en el nivel medio?

¿Cuáles son las principales razones ( además de la "independencia de la base de datos" ) por las que la mayoría de los proyectos de TI parecen ignorar la gran cantidad de características que existen en los motores de bases de datos modernos como Oracle 11g y SQL Server 2008?

O, tomando prestado del blog de la Declaración de Helsinki, que lo expresa de esta manera:

En los últimos veinte años observamos que la funcionalidad (características) que está disponible para nosotros dentro del DBMS, ha crecido exponencialmente. Estas características nos permitieron crear aplicaciones de bases de datos. Que es lo que todos empezamos a hacer en el auge de los noventa.

Pero luego, en los albores del nuevo milenio, sucedió algo. Y ese algo misteriosamente hizo que el papel del DBMS dentro de un proyecto de aplicación de base de datos se redujera a insignificante. (...) A partir del nuevo milenio, estamos empujando toda la lógica de las aplicaciones del DBMS a servidores de nivel medio. La funcionalidad de cosas implementadas fuera del DBMS se ha disparado, y el DBMS rico en funciones apenas se usa para nada más que para almacenamiento en filas.

Estamos hablando de cosas como

• Procedimientos almacenados utilizados como API de datos (por seguridad y para evitar un tráfico de red excesivo)
• Vistas materializadas
• En lugar de disparadores
• Consultas jerárquicas (conectar por)
• Geografía (tipos de datos espaciales)
• Analítica (lead, lag, rollup, cube, etc.)
• Base de datos privada virtual (VPD)
• Auditoría a nivel de base de datos
• Consultas de flashback
• Generación XML y transformación XSL en base de datos
• Llamadas HTTP de la base de datos
• Programador de trabajos en segundo plano

¿Por qué no se utilizan estas funciones? ¿Por qué la mayoría de los desarrolladores de Java, .NET y PHP siguen con el enfoque "SELECT * FROM mytable"?

Porque los procedimientos almacenados:

• agregar otro lenguaje de desarrollo, aumentando la complejidad y el código potencialmente redundante (lógica escrita en ambos lenguajes);
• generalmente tienen peores capacidades de herramientas, monitoreo y depuración que PHP, C #, Java, Python, etc;
• son generalmente menos capaces que la mayoría de los lenguajes de nivel medio;
• solo tiene una ventaja con la transformación de datos de alto volumen (donde evita el viaje de ida y vuelta del servidor), que tiende a ser solo un mínimo de uso real.

Dicho esto, es una metodología común en aplicaciones C # ASP.NET.

Como dijo Jeff Atwood, los procedimientos almacenados son el lenguaje ensamblador de las bases de datos y la gente no tiende a codificar en lenguaje ensamblador a menos que sea necesario.

Con frecuencia utilicé vistas materializadas y, a veces, utilicé CONNECT BY en Oracle, ninguna de las cuales creo que existe en MySQL.

No suelo usar XML / XSLT en la base de datos porque, bueno, eso significa que estoy usando XML y XSLT.

En cuanto a las estructuras de datos geográficas o espaciales, la razón probablemente sea que son difíciles de "captar". Es un área bastante especializada. He leído el manual de MySQL sobre estructuras de datos espaciales y estoy seguro de que tiene sentido para alguien con una amplia experiencia en SIG, pero para mí y mis necesidades limitadas (que tienden a marcar la latitud / longitud de un punto) simplemente no lo hace. No parece que valga la pena invertir tiempo en resolverlo.

Otro problema es que si va más allá de ANSI SQL (mucho), entonces se ha atado un poco a un proveedor de base de datos en particular y posiblemente a una versión específica. Por esa razón, a menudo encontrará que los desarrolladores de aplicaciones tienden a tratar sus bases de datos con el mínimo común denominador, lo que significa tratarlas como un vertedero de datos relacionales.

Porque los desarrolladores no conocen SQL. Se basan en DDL y DML generados por herramientas como Hibernate y construcciones de nivel de lenguaje como anotaciones JPA. A los desarrolladores no les importa si estos son terriblemente ineficientes porque afortunadamente están ocultos por los niveles de registro normales y porque los DBA no forman parte de los equipos de desarrollo.

Por eso me gustan las herramientas iBATIS . Le hacen escribir y comprender SQL, incluidas las características específicas de DBMS.

Supongo que una de las razones es el miedo al bloqueo de los proveedores.

Esto no se dice con tanta frecuencia, pero los beneficios de utilizar funciones específicas del proveedor deben sopesarse con el costo. Principalmente, el costo de tener que reescribir las partes que dependen de características específicas del proveedor para cada base de datos que desea respaldar. También hay un costo de rendimiento si implementa algo de una manera de propósito general cuando el proveedor proporciona una mejor manera.

Traeré este ejemplo: uno podría encontrar que el "bloqueo" de SQL Server sea más aceptable una vez que se dé cuenta de todas las cosas que Analysis Services, Reporting Services, etc. pueden hacer por su aplicación. Para los principales sistemas de bases de datos comerciales, no es "sólo" el motor de base de datos SQL lo que debe tenerse en cuenta.

"Por qué se ignoran las características de la base de datos".

Debido a que muchos de los llamados desarrolladores ignoran por completo la gestión de datos y, lo que es peor, también ignoran por completo su ignorancia. "Inexperto y sin saberlo", para quien esto suena familiar.

Si su software se ejecuta en el hardware de su cliente, cualquier cambio en la base de datos (nuevos procedimientos almacenados, vistas actualizadas, etc.) requerirá derechos de administrador de la base de datos. Esto es casi siempre un problema para los clientes. La participación del grupo de bases de datos complica las actualizaciones que debe realizar. Aquí se presentan muchas buenas razones, pero esta es la única que necesito para evitar poner código en la base de datos como una plaga.

Supongo que una de las razones es el miedo al bloqueo del proveedor. Estas características de DBMS no están estandarizadas; por ejemplo, los procedimientos almacenados son muy específicos de DB, y si implementó cosas usando procedimientos almacenados (en lugar de, digamos, servicios web expuestos a través de un nivel medio), entonces estará atrapado para siempre con el DBMS elegido primero. , (es decir, a menos que esté dispuesto a gastar tiempo / dinero para volver a implementarlo en otro DBMS si desea cambiar el DBMS).

MySQL.

Cuando las aplicaciones web explotaron a fines de la década de 1990 y principios de la de 2000, MySQL tenía la versión 3.3 o 4.0 y no admitía nada por encima de los simples SELECT. Sin embargo, era gratuito y se instalaba con la mayoría de las distribuciones de Linux. Como resultado, una generación de programadores no aprendió sobre bases de datos y no sabía cómo usarlas.

Incluso ahora que MySQL está en 5.1 y es compatible con la mayoría de las características de un sistema comercial, los mismos blogs y artículos viejos y rudos se usan como plantillas cuando se inicia un nuevo proyecto LAMP, y MySQL se implementa con tablas MyISAM y funcionalidad de la era 3.3 .

SQL falla por la misma razón que, por ejemplo, Haskell. La métrica que determina el éxito del lenguaje no es la pureza, ni la facilidad de interpretación por parte de las computadoras, sino lo difícil que es mantener los programas escritos en él.

Los simples mortales fracasan incluso con el lenguaje más simple. Quizás 1 de cada 10 personas tiene las habilidades para usar un lenguaje sencillo como C #. Pero de ese 10%, solo 1 de cada 10 o 1% de todas las personas pueden usar lenguajes como SQL o Haskell de manera efectiva.

Ahora, SQL está incompleto como lenguaje, en el sentido de que hay muy pocas cosas que puede hacer solo con SQL. Siempre necesitarás otro idioma. ¿Qué papel deja eso para SQL? Los desarrolladores comprenderán las ventajas de ACID sobre el almacenamiento de archivos planos, pero además de que las bases de datos realmente no tienen nada que ofrecerles.

Un segundo problema es que SQL efectivamente no es muy compatible con el control de versiones de origen. SQL parece realmente construido con la noción de que lo haces bien la primera vez. Por lo tanto, no solo es inadecuado para los desarrolladores, también es una mala combinación para el proceso de desarrollo.

Es más fácil arreglar / volver a implementar el nivel medio que el DBMS.

Probablemente esto dependa de su arquitectura, pero es nuestra razón. Combine eso con el hecho de que tenemos un DBA que está más ocupado y (probablemente) se le paga más que a nuestros desarrolladores. Todos los desarrolladores conocen SQL y algunos de ellos están semi-versados ​​en el lenguaje procedimental. Si surge un problema de producción realmente complicado, sería más fácil y rápido para los desarrolladores trabajar en el nivel medio que en la base de datos, independientemente de si la arquitectura sería mejor de una forma u otra.

Me he encontrado con bastantes personas que simplemente no sabían que existían tales características: se cortaron los dientes en los primeros días de mySQL, y nunca han usado nada más, y no se han mantenido al día el avance de las nuevas tablas de almacenamiento en mySQL, incluso. O aprendieron bases de datos en la escuela y nunca regresaron para ver todas las cosas que se perdieron.

Aprenden el SQL mínimo para sobrevivir y no se dan cuenta de todas las diferentes extensiones que ofrecen los diferentes RDBMS.

En un proyecto, me encantaría tener vistas materializadas ... pero estoy usando Postgres. Me encantaría usar tipos de datos espaciales para otro proyecto, pero tendré que hacer un truco o cambiar las bases de datos para lidiar con la insistencia de mySQL de que no sean nulos. Incluso tuve que averiguar cómo deshabilitar la coherencia transaccional de Oracle para hacer frente a consultas de larga duración en un OLTP que no habrían sido un problema en mySQL.

Normalmente puedo codificar las deficiencias de la base de datos para un problema dado, pero parte del problema es seleccionar la herramienta adecuada para el trabajo; en un proyecto actual, hemos desperdiciado meses-hombre en la replicación de datos porque estamos usando Postgres, y se decidieron por Slony-1 antes de saber realmente todo lo que estaríamos replicando.

... Veo esta pregunta como '¿por qué más personas no usan la característica x en el idioma y? '. Si no son expertos en el idioma y, es posible que no sepan que la característica x existe.

(y no tome esto como soporte para obtener la certificación DBA ... He conocido a algunos DBA de Oracle que no pudieron programar su salida de un saco húmedo; tomé todos los cursos en los días 8i, pero se negó a tomar las pruebas porque no quería que me agruparan en ese grupo)

Creo que la razón principal por la que eclipsa a todas las demás es que los sistemas de bases de datos relacionales se vuelven mucho más importantes cuando varias aplicaciones comparten los mismos datos. El famoso artículo de Codd se titula "Un modelo relacional de datos para grandes bancos de datos compartidos " (el énfasis es mío).

La gente tiende a pensar que la aplicación que están escribiendo ahora siempre estará controlada por su equipo; y que siempre satisfará todas las necesidades de las personas interesadas en los datos generados por la aplicación. Si surge una nueva necesidad, se satisfaría agregando una nueva función a una aplicación existente, no creando una nueva aplicación.

Pero en muchos casos (no todos, por supuesto; cada situación es diferente), ese modelo de desarrollo no funciona muy bien a largo plazo. A medida que los datos generados por la aplicación se acumulan y se vuelven más importantes para el negocio, diferentes personas tendrán ideas interesantes sobre cómo utilizar los datos. Cuando eso sucede, si no tiene un sistema de administración de bases de datos relacionales, se encontrará con un gran desafío.

Escalabilidad. Cuanto más trabajo le dé al servidor de la base de datos, mayor será el cuello de botella. Es más escalable tener una granja completa de servidores de aplicaciones con equilibrio de carga que procesan los datos y solo usan la base de datos como un almacén de persistencia.

He estado en demasiadas situaciones en las que la política corporativa ("no se nos permite el acceso al servidor SQL, así que instalemos un DBMS menos poderoso como Access para procesar millones de filas y unir eso con millones de filas en otra tabla, y automaticemos esa importación .. ") o incluso las políticas técnicas que pueden suceder (" Sé que Access puede manejar esa cantidad de datos e incluso si no lo hace, podemos dividir el MDB en varios MDB y hacer referencia a ellos ... ")

UGH. La política corporativa y la política técnica o incluso la ignorancia me han impedido utilizar muchas funciones.

Otro ejemplo: no veo ninguna razón para no usar procedimientos almacenados en una tienda 100% Microsoft donde SQL Server es el DBMS de elección. Pero, debido a que el tipo de TI que eventualmente iba a poseer la solución era "liviano" en los SP, tuve que recurrir a otras medidas. Quiero decir, hay un ejemplo perfecto de por qué algunas de esas "características" fueron ignoradas por ellos en su tienda.

Conozco otra tienda que todavía usa DOS Foxpro 2 porque su único informático escribió el sistema existente de esa manera y así es como se desarrollarán todas las cosas nuevas. ¿Por qué? ¿No podemos seguir el ritmo de los tiempos? Mucha de la gente de marketing de allí tiene varios avisos de DOS abiertos a la vez, con "trabajos" de Foxpro ejecutándose en ellos para producir los informes más feos que he visto. Pero funciona, les daré eso. Funciona: tienen 12 millones de filas en su tabla principal y más de 50 tablas más que 'unen' con esa tabla principal (no todas las 50 a la vez, obviamente) pero hombre ... ¡ya pasó 1991! Ni siquiera quieren discutir un elemento de esa lista de viñetas que proporcionó en su pregunta.

Cosas como esta es la razón por la que supongo.

Yo diría que la principal razón es que la mayoría de la gente no los conoce. Una vez que alguien ha descubierto una solución a un problema, esa se convierte en la solución predeterminada para otros similares. La tabla SELECT * FROM ha funcionado para muchas personas durante mucho tiempo, por lo que no se molestan en buscar nuevos enfoques para problemas antiguos.

La otra razón es que a veces escribirlo en código es mucho más fácil que usar una base de datos. Es la misma idea que rodar por su cuenta frente a comprar un componente listo para usar. El uso de una función preescrita puede resolver sus problemas muchas veces, pero de vez en cuando, debe hacer algo que está fuera de las capacidades de los componentes preescritos.

Buena pregunta y buena discusión.

Otra forma de decirlo es "¿por qué no se han puesto al día las bases de datos de objetos?" que es la otra cara de la moneda. Las bases de datos continúan siendo una abstracción molesta que aún se filtra en todas las aplicaciones, pero son incompatibles con la lógica OO de las aplicaciones modernas.

De hecho, es una situación extraña que ocultemos y dupliquemos la funcionalidad de las bases de datos en ActiveRecord, Hibernate y otros middlewares. Pero esto es lo que sucede con los paradigmas en el punto de ruptura (el "desajuste de impedancia relacional de objeto"). ¿Alguna vez pasaremos a tecnologías de bases de datos que sean similares a nuestras aplicaciones OO (por ejemplo, bases de datos de objetos)?

La respuesta es "no por mucho tiempo" y, mientras tanto, espere que la base de datos sea ignorada y aplastada y utilizada solo para el almacenamiento de filas en muchos casos, a medida que el nivel medio crece en funcionalidad para cerrar la brecha.

Otra pregunta es "¿por qué debería hacerlo en la base de datos si el nivel medio puede hacerlo?" El nivel medio es familiar y gana terreno en velocidad y funcionalidad todo el tiempo. Nuevamente, usamos el nivel medio para evitar la discrepancia entre OO y RDMS.

Avanzar en lo que dijo Christian , sobre escalabilidad.

Simplemente, los RDBM se están utilizando más como almacenes de datos puros, mientras que la lógica se ha estado migrando a los servidores de aplicaciones. El nivel adicional de AS brinda a los desarrolladores más flexibilidad que el uso de RDBMS como servidor de aplicaciones.

Antes, en los días clásicos de Fat Apps y Client Server, la base de datos y el servidor de aplicaciones eran básicamente lo mismo. Tenía la lógica de la aplicación incrustada en el código de su cliente pesado o la devolvió al RDBMS. Pero en ese entonces, la forma principal de comunicación era SQL directamente a la base de datos.

Hoy en día, otros protocolos de aplicación son más comunes (CORBA, DCOM, Remote EJB, y cada vez son más comunes los protocolos de estilo XML / JSON / HTTP-RPC sobre HTTP). La mayoría de las bases de datos no responden directamente a esos protocolos, por lo que se interpone una capa de aplicación para interceptar esas llamadas, y esa capa llama a la base de datos.

Pero como hemos aprendido, ahora obtenemos mucha más flexibilidad al poner lógica en esta capa. Mayor variedad de herramientas, más flexibilidad sobre el almacenamiento en caché o conmutación por error, o incluso tecnología de base de datos (RDMBS, OODBMS, almacenes de documentos como CouchDB). Ese tercer nivel "nuevo", a pesar de la complejidad añadida, añade más flexibilidad y potencia que la complejidad que introduce.

Cuando el nivel de su aplicación es una capa muy fina sobre los procedimientos almacenados, es válido preguntarse por qué está allí.

Aprovechar la base de datos y todas sus características es una estrategia de aplicación válida, incluso hoy. SQL Server, Oracle, etc., son piezas de software terriblemente poderosas.

Incluso entonces, sin embargo, el tercer nivel es enormemente útil para agregar flexibilidad a un sistema moderno.

Para mí, la razón no es solo que mis aplicaciones sean independientes de la base de datos, sino que una base de datos preforma mejor las funciones básicas de CRUD. Sí, las bases de datos están altamente optimizadas y es posible que puedan hacer una llamada HTTP, pero ¿por qué lo haría? Un servicio web / aplicación web está optimizado para llamadas HTTP, no una base de datos. Al igual que una aplicación no está diseñada para conectarse directamente a un archivo de datos y recuperar los datos. Se puede hacer? ¿Si, pero por qué? Eso no es lo que su aplicación EXCELE.

Personalmente, creo que todo lo que mencionó, fuera de los procedimientos almacenados, pertenece a la aplicación. Si sabe que su arquitectura es X, aproveche las características de X, transfiera la carga al servidor de base de datos cuando sea apropiado, etc. Si pudiera ser X o Y (o Z), entonces su aplicación debe ser agnóstica, a menos que usted sea tratando de crear seguridad laboral asegurándose de que es posible que tenga que refactorizar la aplicación :). Creo que un poco de pereza, combinado con comodidad, podría tener algo que ver con eso. Sé que preferiría hacerlo en C # que en SQL si puedo. . . mis habilidades de C # son simplemente mejores.

En primer lugar: cualquier desarrollador que use un ORM es ingenuo si piensa que usar un ORM niega tener que tener habilidades de SQL. La mayoría de los ORM que generan SQL varían el SQL emitido dependiendo de cómo se construyan las consultas de objeto. El desarrollador deberá analizar el SQL para ver si debe cambiar alguna de las consultas de objeto.

Respuesta corta: muchas de esas características no son prácticas para el desarrollo de OO. Sé que a los DBA no les gusta escuchar eso, pero es la verdad. Esas características son buenas para casos extremos y la mayoría de los ORM buenos, como N / Hibernate, le permiten proporcionar SQL para esos casos extremos.

Cuando se trata de ser delegado mayoritariamente a CRUD:

Respuesta larga: Creo que el mundo de RDBMS está atravesando dolores de madurez y está encontrando su lugar en el mundo. Verdad: OOP es más antiguo que RDBMS. OOP solo está saliendo de sus dolores de crecimiento y madurando. Creo que SQL como lenguaje es muy maduro, pero la idea de lo que debería manejar un RDBMS apenas se está asentando. El RDBMS fue el soporte de la lógica empresarial para la mayoría de las aplicaciones web hasta que aparecieron Java y C #. Creo que ahora estamos empezando a sentir esta corrección.

Dicho esto, no creo que ningún diseñador de ORM le diga que la calidad de las declaraciones sql alimentadas al RDBMS no importa.

Cuando se trata de no CRUD, no tengo una respuesta aquí. La mayoría de las tiendas que conozco todavía usan la base de datos para ETL / etc ...

No hay suficientes desarrolladores que conozcan todas esas características a un nivel que realmente marcaría la diferencia para un programador normal de 'nivel medio', cuando se trata de implementar la misma lógica en la base de datos o el nivel medio. Quizás las personas solteras que realmente tienen un conocimiento profundo de esas características son los administradores de bases de datos. Y esos se centran en otros problemas además del desarrollo. Hay más desarrolladores "normales" que los administradores de bases de datos. Por lo tanto, sería muy difícil y costoso encontrar a las personas adecuadas para su equipo.

Otro punto es que normalmente solo recopilará el conocimiento profundo sobre un sistema de base de datos, y no todos. Por lo tanto, puede tener expertos en SQL Server o expertos en Oracle, pero no ambos. Esto conduce (hasta cierto punto) a campos de aplicación reducidos donde cuenta una alta especialización. Entonces, el mercado para tales aplicaciones no es tan grande, incluso si existe.

Creo que la razón es una combinación de dependencia del proveedor y falta de conocimiento por parte de la mayoría de los usuarios de RDBM. SQL es un lenguaje de programación, y es mucho más difícil dominar el lenguaje desde el que está llamando SQL y SQL que dominar uno u otro, especialmente porque SQL es un lenguaje particularmente único.

Creo que la solución es abstraer la funcionalidad de su base de datos en una clase de utilidad y dar la propiedad de la clase a unos pocos usuarios que saben lo que están haciendo con SQL. Esto minimiza el riesgo de bloqueo del proveedor (si cambia de proveedor, lo único que se reescribe es la clase). Esto también brinda a los desarrolladores que no son expertos en SQL una interfaz extraída para que no tengan que lidiar con la base de datos directamente.

Una de las preocupaciones que he visto al aprovechar una mayor funcionalidad de la base de datos es el escalado. Parece ser una propuesta mucho más difícil escalar la carga de su base de datos en comparación con la carga del servidor web / de aplicaciones.

Sus opciones son limitadas, escaladas con hardware más grande y más rápido (con costos de licencia a veces mucho más altos) o complicadas, escaladas con copias de solo lectura, etc.

Si hay problemas de rendimiento, quiero que estén en el nivel de la aplicación del servidor web. Al menos una de mis opciones es agregar otro servidor web y distribuir la carga.

No estoy discutiendo contra el código de nivel de base de datos para minimizar la cantidad de tráfico de red (registros) enviado entre el servidor web y el servidor de base de datos. Estoy discutiendo contra otras características, por ejemplo. Amplio procesamiento de lógica empresarial a nivel de base de datos.

Algunas publicaciones señalan que es más barato escalar en la capa de aplicación que en la capa db.

Otra consideración son las aplicaciones compuestas que acceden a múltiples almacenes de datos. Es mucho más fácil escribir y mantener un lenguaje de consulta independiente de la plataforma en el nivel de la aplicación que las consultas específicas de la plataforma separadas en el nivel de la base de datos.

Porque escribir software orientado a objetos, en el lenguaje anfitrión, con objetos nativos del lenguaje anfitrión, es mejor que escribir software de procedimiento.

Siempre he trabajado en sistemas que se venden a muchos clientes y se ejecutan en el hardware del cliente. Esto lleva a:

• No sabe qué versión del software de base de datos ejecutará el cliente.
• Es posible que los clientes no estén dispuestos a actualizar el software de la base de datos cuando lo deseen debido a los costos de licencia o la política de TI.
• Incluso las características básicas como las vistas materializadas están solo en algunas "ediciones" del software de la base de datos, los clientes más pequeños a menudo no están dispuestos a pagar por la edición de gama alta de la base de datos.
• Tarde o temprano, uno de sus vendedores aceptará que su software se utilice con un RDBMS de otro proveedor.
• ¡Elegir entre escribir la lógica una vez en el nivel medio, o al menos PL-SQL y TSQL en la base de datos es una elección fácil!
• Cualquier cambio en la base de datos (nuevos procedimientos almacenados, vistas actualizadas, etc.) requerirá derechos de administrador de la base de datos; Esto puede ser mucho más difícil en el sitio de algunos clientes que simplemente actualizar su software.
• Escribir un script para actualizar la base de datos siempre es más difícil que instalar una nueva versión de las DLL de la aplicación. (La mayoría de los sistemas de compilación en estos días generan archivos MSI como parte de cada compilación)
• Es más difícil probar un código en una base de datos que en un nivel medio.
• Es más difícil depurar procesos almacenados que C #.
• El hecho de que funcione en su base de datos no significa que funcionará en la base de datos del cliente, RDBMS tiene demasiados conmutadores que cambian su funcionamiento; los clientes siempre tienden a configurarlos de diferentes maneras.

Entonces, dado todo lo anterior, la ganancia de usar una función de base de datos debe ser grande antes de que valga la pena el dolor a largo plazo.