¿Por qué tiene sentido envolver sus modelos de bases de datos relacionales en objetos?

Cuando tiene una aplicación web bastante grande y / o compleja, es mejor que no tenga que preocuparse por traducir los modelos de datos de su aplicación a modelos de bases de datos. Es por eso que es mucho más fácil escribir una aplicación web empresarial en algo como Django: haces todo con objetos de Python y dejas que el ORM se ocupe de cómo se escribirán y leerán los objetos desde la base de datos.

Cuando su aplicación es realmente simple, el andamiaje que se necesita para trabajar con objetos (y tratar de definirlos para que el ORM pueda hacer lo suyo) puede no valer el tiempo y el esfuerzo para implementarlo. Pero a una cierta complejidad, el mantenimiento del proyecto se vuelve mucho, mucho más difícil si tiene que lidiar con la traducción de cómo deben almacenarse las cosas en una base de datos frente a la mayor flexibilidad de los objetos en el lenguaje de programación (moderno) que elija.

Esto suena como una pregunta sobre los pros y los contras de la abstracción de la base de datos. Soy un gran admirador de la abstracción de bases de datos y personalmente nunca construyo una base de datos sin una. Incluso si la base de datos es SQLite.

Entonces, ¿qué es una abstracción de base de datos?

Una capa de abstracción de base de datos proporciona una serie de funciones en una base de datos. Hablaré de algunos de los principales que me gusta socializar. Las herramientas de capa de abstracción importantes son las API de bases de datos (procedimientos, funciones, paquetes) y vistas.

Seguridad: en los sistemas donde la seguridad es una preocupación, una tabla puede almacenar un campo encriptado como tarjeta de crédito o hash de contraseña. Aunque está encriptado en una tabla de base de datos, el único rol que debería poder seleccionar de una columna encriptada es un rol de desarrollo de db. Considere la base de datos en este ejemplo en un servidor separado que no está expuesto al mundo y podría bloquearse con solo la dirección IP de la aplicación que se le permite conectarse. El servidor de aplicaciones que no está bloqueado y expuesto al mundo entero solo puede seleccionar desde una vista que abstraiga toda la tabla y solo exponga algunos de los campos no cifrados. Esto garantiza que si el servidor de aplicaciones se vio comprometido, nunca podría ver el campo cifrado. Cuando un usuario del servidor de aplicaciones desea interactuar con campos encriptados, pasa parámetros a una API que abstrae los campos seguros y devuelve solo los resultados requeridos y los datos encriptados no necesitan salir de la DMZ. Otro buen ejemplo es donde se necesita seguridad a nivel de fila (FGAC).

Perspectiva de consumo desde la perspectiva de una aplicación, independientemente de la implementación de datos: tengo una fuerte opinión de que los datos deben modelarse en función de los datos. Esto suena obvio pero no es tan común como piensas. Estoy bien con un tema común con la mayoría de los sistemas con problemas de escalabilidad de la base de datos que me arreglaron como resultado de un desarrollador de Java que construye tablas basadas en su modelo de objetos sin tener en cuenta el modelo real de los datos que está afirmando. Tener una capa de abstracción le permite modelar físicamente datos basados ​​en los datos, pero presentar esos datos en el modelo de objeto deseado a la aplicación. Esto es especialmente útil cuando varias aplicaciones dispares comparten datos pero tienen diferentes modelos de objetos. También se pueden usar muchos trucos de ajuste de rendimiento dentro de la vista para acelerar la traducción de datos desde su implementación física hasta su consumo por parte de la aplicación.

Lógica empresarial: puede haber mucho debate sobre dónde colocar la lógica empresarial. En general, prefiero poner la lógica empresarial sobre los datos lo más cerca posible de los datos. La implementación de este sesgo significa que me gusta poner lógica empresarial en la base de datos. Esto tiene una serie de características; protege la lógica de negocios, múltiples aplicaciones dispares pueden consumir la lógica de negocios una vez en lugar de mantener ese código en lugares separados y también brinda oportunidades para ajustar el rendimiento de los procesos de negocios basados ​​en datos con herramientas RDBMS que a menudo son más adecuadas para manejar problemas de rendimiento de datos. Si solo hace lógica de negocios en la aplicación, nunca puede tratar de usar herramientas RDBMS para ajustar el rendimiento, lo que parece bastante ingenuo y limitante para tener una herramienta pero no usarla. o … Si no está utilizando las características de la base de datos, ¿por qué no solo usar archivos planos? Nota: A veces, la aplicación sigue siendo el lugar adecuado para hacer una lógica comercial relacionada con los datos, pero prefiero comenzar con la base de datos.

Ver abstracciones ayuda a aislar el desarrollo de la aplicación de los cambios causados ​​por el desarrollo de la base de datos. Algunas veces es útil realizar cambios en la base de datos por una serie de razones que no tienen nada que ver con la aplicación que la consume. Si tiene una capa de abstracción, puede hacer cambios drásticos en la estructura subyacente, pero mantener la capa de abstracción igual y hacer cosas como mejorar el rendimiento, la seguridad, la facilidad de administración de datos, etc. y causar cero reescritura para la aplicación que consumirá los datos.

Para mí, solo hay ventajas y desventajas en una capa de abstracción de base de datos.

El único inconveniente que conozco es que podría ser difícil para algunos si nadie en el equipo lo sabe / quiere hacerlo.