¿Deberían usarse las bases de datos solo para persistencia?

Question

Muchas aplicaciones web que tienen una arquitectura de 3 niveles están haciendo todo el procesamiento en el servidor de aplicaciones y usan la base de datos para la persistencia solo para tener independencia de la base de datos. Después de pagar una gran cantidad por una base de datos, hacer todo el procesamiento, incluido el lote en el servidor de aplicaciones y no usar la potencia de la base de datos parece ser un desperdicio. Tengo la dificultad para convencer a las personas de que necesitamos usar lo mejor de ambos mundos.

Answer 1

Depende de su aplicación. Debe configurar las cosas para que su base de datos haga las cosas para las que las bases de datos son buenas. Una unión de ocho tablas a través de decenas de millones de registros no es algo que quiera manejar en su nivel de aplicación. Tampoco realizar operaciones agregadas en millones de filas para emitir pequeños piezas de información sumaria.

Por otro lado, si solo está haciendo mucho crud, no está perdiendo mucho tratando esa gran base de datos costosa como un repositorio tonto. Pero los modelos de datos simples que se prestan al "procesamiento" centrado en la aplicación a veces terminan llevándolo en el camino hacia ineficiencias imprevistas. Diseño de nudos. Te encuentras procesando registros en el nivel de aplicación. Mirar las cosas de manera que comienzan a aproximar las uniones de SQL. Eventualmente, refactora dolorosamente estas cosas al nivel de la base de datos donde ejecutan órdenes de magnitud de manera más eficiente ...

Entonces, depende.

Answer 2

¿Qué "potencia" de la base de datos no está utilizando en una archiectura de 3 niveles? Presumiblemente explotamos SQL al máximo, y toda la gestión de datos, paginación, almacenamiento en caché, indexación, optimización de consultas y capacidades de bloqueo.

Supongo que el argumento es donde se debe implementar lo que podríamos llamar "lógica comercial". En el servidor de aplicaciones o en el procedimiento almacenado de la base de datos.

Veo dos razones para ponerlo en el servidor de aplicaciones:

1). Escalabilidad. Es relativamente difícil agregar más motores DATBASE si el DB se ocupa demasiado. La división de datos en múltiples bases de datos es realmente complicado. Por lo tanto, extraiga la lógica de negocios al nivel del servidor de aplicaciones. Ahora podemos tener muchas instancias de servidor de aplicaciones que hacen lógica de negocios.

2). Mantenimiento. En principio, el código de procedimiento almacenado puede estar bien escrito, modularizado y resioso. En la práctica, parece mucho más fácil escribir un código mantenible en un lenguaje OO como C# o Java. Por alguna razón, la reutilización en los procedimientos almacenados parece suceder al cortar y pegar, por lo que con el tiempo la lógica comercial se vuelve difícil de mantener. Concedería que con la disciplina no necesita suceder, pero la disciplina parece ser escasa en este momento.

Debemos tener cuidado de explotar realmente las capacidades de consulta de la base de datos al máximo, por ejemplo, evitando la extracción de grandes cantidades de datos al nivel del servidor de aplicaciones.

Answer 3

No. Deben usarse también para la aplicación de las reglas comerciales.

Por desgracia, los DBMS Big Dogs no son lo suficientemente competentes o no están dispuestos a apoyar esto, lo que hace que este ideal sea imposible y mantenga a sus clientes como rehenes a sus principales vacas de efectivo.

Answer 4

He visto una aplicación diseñada (por un tipo bastante inteligente) con tablas de la forma:

id | one or two other indexed columns | big_chunk_of_serialised_data

El acceso a eso en la aplicación es fácil: existen métodos que cargarán uno (o un conjunto) de objetos, deserializándolo según sea necesario. Y hay métodos que serializarán un objeto en la base de datos.

Pero Como se esperaba (pero solo en retrospectiva, lamentablemente), ¡hay tantos casos en los que queremos consultar el DB de alguna manera fuera de esa aplicación! Esto se hace de varias maneras: una interfaz de consulta ad-hoc en la aplicación (que agrega varias capas de indirección a obtener los datos); reutilización de algunas partes del código de la aplicación; Código de deserialización escrita a mano (a veces en otros idiomas); y simplemente tener que prescindir de los campos que estén en la parte deserializada.

Puedo imaginar fácilmente lo mismo ocurre para casi cualquier aplicación: es solo práctico para poder acceder a sus datos. En consecuencia, creo que sería bastante reacio a almacenar datos serializados en un DB real, con posibles excepciones en las que el ahorro supera el aumento de la complejidad (un ejemplo almacena una serie de INT de 32 bits).