Extraído de otro hilo: gestión de datos y objetos de negocio

On Mon, 22 Jan 2007 21:07:35 +0100, "Hoze \(SMM\)"
wrote:

Yo trabajo en la misma línea que tú. No soy partidario de utilizar el SGBD
para darle lógica a una aplicación.

No creo que nadie lo sea, pero se debe de utilizar un SGBD para
gestionar los datos del SISTEMA y dejar que las aplicaciones se ocupen
solo de la presentación y la comunicación. Si no lo haces así no estás
separando bien los problemas.

http://en.wikipedia.org/wiki/Separa...f_concerns

Siempre he basado mis aplicaciones en
modelos de objetos y la lógica de negocio la diseño e implemento en mi soft,
no en la base de datos.

Un disparate. Muy mal hecho.

Siempre que "lógica de negocio" signifique lo que normalmente
significa, claro.

Pienso que es un modelo más flexible: independiza mi
desarrollo de la base de datos, me permite trabajar en distintos entornos y
con distintas configuraciones hardware y software.

Y hacer la contabilidad a mano bajo la luz de una vela te independiza
del software, el hardware y las compañías eléctricas.

El uso de la tecnología crea dependencias, pero muchas veces vale la
pena.


Saludos
Alfredo

Hola,

On 22 Jan 2007 09:51:57 -0800, "Roberto M. Oliva"
wrote:

Yo creo que se habla segun lo que cree cada uno que es mejor.

Y también según lo que se sabe que es mejor. Que unos no sepan no
quiere decir que nadie sepa lo que es mejor.

Yo por mi experiencia siempre prefiero tratar la logica de negocio con
programacion orientada a objetos.

La experiencia del ignorante tiene muy poco valor. Es como el que
lleva toda la vida tratando la gripe con antibióticos. Al final la
mayoría se acaban curando, pero no han hecho bien las cosas.

Modelo en la base de datos la
estructura basica de las entidades: campos unicos, indices, integridad
referencial, etc. Pero no suelo tener ni vistas ni procedimientos
almacenados ni triggers.

Con lo que estás desaprovechando recursos muy valiosos.

Tampoco uso DataSets. Nunca he visto el beneficio de su escalabilidad
en los proyectos en los que he trabajado, por lo que he preferido tirar
por un software mas facil de desarrollar que a uno que sea muy
escalable.

Decir que es más fácil desarrollar con "objetos de negocio" que con
datasets es una gran mentira.

Pero esto depende del entorno final del proyecto.
Si te sirve de algo, mi experiencia me ha decantado por el desarrollo
de la capa de negocio con patrones de diseño. Sobre todo: ActiveRecord

El falso patrón Active Record es una forma estupenda de recortar las
capacidades de un SGBD SQL. Es como meter un televisor dentro de una
caja para fabricar una radio. Partes de un sistema pensado para tratar
los datos como conjuntos y acabas con un primitivo procesador de
registros. Genial.


Saludos

On Mon, 22 Jan 2007 21:17:58 +0100, "Hoze \(SMM\)"
wrote:

¿Qué responsabilidad y qué
grado de dependencia de la bbdd estáis dando a la base de datos?

Esta frase no tiene sentido.

Sí lo tiene. El grado de dependencia de la BBDD depende del uso de SPs,
tipos de datos específicos, funciones, lenguaje de los SP's, definición de
las particiones de la base de datos, gestión de seguridad, etc...

Has escrito: que grado de dependencia tiene la base de datos de la
base de datos.

Si querías decir que no es sencillo sustituir un DBMS por otro pues
claro que no. Eso es señal de que estás aprovechando bien sus
capacidades y no te limitas al máximo común denominador, que suele ser
muy pequeño. La dependencia es un precio muy pequeño que hay que pagar
por las enormes ventajas de aprovechar un SGBD en todo su potencial.

Para lograr mayor independencia del SGBD SQL se puede usar un
middleware como Dataphor o Datajoiner, pero en ese caso creas
dependencia con el middleware.

¿Qué aporta un dataset?

Facilita la presentación de los datos y es una clase reutilizable.
Aunque se podría mejorar muchísimo.

Y ya.

Es que eso es lo que tiene que aportar. También podría desencriptar
DVD, pero los datasets no son para eso.

Las aplicaciones no deben de abstraer ni gestionar los datos. Para eso
está el SGBD.

No estoy de acuerdo. El SGBD es un almacén de datos,

Acabas de demostrar que no tienes ni la más remota idea de teoría de
bases de datos. Este es uno de los mayores errores que se pueden
cometer a la hora de desarrollar un Sistema de Información.

y tu desarrollo, a
niveles superiores, tiene que estar completamente aislada de:
- Qué SGBD se utiliza como almacén de datos
- Cómo están definidos estos datos
- Cómo se recuperan y cómo se almacenan

Un SGBD sirve entre otras cosas para aislar a las aplicaciones de como
están almacenados físicamente los datos. Esto lo puedes aprender en el
primer capítulo de cualquier libro de texto de la asignatura de bases
de datos.

Los datos se filtran con consultas SQL.

Claro, cuando los recuperas, pero luego ponte a trabajar con ellos...

Es que no hay que trabajar con ellos después de recuperarlos. Se deben
de recuperar listos para presentar. Para eso están las consultas.


Saludos
Alfredo

Sí lo tiene. El grado de dependencia de la BBDD depende del uso de SPs,
tipos de datos específicos, funciones, lenguaje de los SP's, definición de
las particiones de la base de datos, gestión de seguridad, etc...

Sacando lo de tipos de datos especificos, no creo que ninguno de los demas
que citas sean puntos de dependencia de una BD.
Los SP's, funciones, etc de una BD puedes verlos con blackboxes. Solo
necesitas saber los parametros y lo que devuelven.
En el peor de los casos te creas un namespace para las particularidades. Es
algo similar a lo que hace .net con un namespace
especializado para sql server, otro para oracle, etc. y uno generico.

Estaba yo 'componiendo' esta respuesta para Rogelio en el otro
thread cuando de repente veo que se ha habierto aqui otra.
Pues ahí va! Y no va especialmente dirigida a Rogelio.

Rogelio schreef:

>
>
> Alguien que no se enteraba muy bien de las cosas lo confundió todo y
> pensó que eso de las tres capas se refería a las aplicaciones, y un
> montón de incautos le han seguido y ha surgido una leyenda urbana que
> dice que las aplicaciones tienen que tener tres capas, una de datos,
> otra de lógica de negocio y otra de presentación. Menuda tontería.
>
>

La capa de logica de negocio reside entonces en la misma base de datos?

Si.
Recordemos que 'reglas de negocio' son especificaciones informales
de lo que al fin y al cabo son constraints de integridad de datos.

Te refieres a el conjunto de funciones, store procedures, views, etc. que
sirven para acceder indirectamente a los datos?

== Aclaración =Si he entendido bien, con 'indirectamente' te refieres a llamar
stored procedures desde las aplicaciones en vez de usar los select/
insert/update/delete; entonces no, no se trata de eso. Las stored
procedures mismas pueden considerarse 'pequeñas' aplicaciones que
van con la BBDD.

Bueno... vamos allá...

== Into =Se trata sobre todo de derivación de datos (p.e. views, que también
se usan para darle nombres a tablas y atributos según la
expectaciones de las distintas aplicaciones) y de declación de
constraints, por ejemplo checks, que serán los que controlen la
integridad de los datos. Bueno.. los views también controlan
integridad claro; la de los datos que derivan.

== Constraints / Triggers =Reglas de integridad que no se puedan especificar declarativamente
(por ejemplo con checks) tendrían que programarse proceduralmente
en triggers, pero ese debe ser el último recurso; mejor de forma
declarativa. Hacerlo proceduralmente hace que la eficiencia sea
dependiente de estructuras físicas, como de la existencia de un
índice determinado. Pensemos por ejemplo en la utilización de un
cursor dentro de otro cursor. Se fija asi una estrategia de acceso
que puede resultar muy ineficiente y que hecho de forma declarativa
podría darle al SGBD la oportunidad de escoger otra estrategia
dependiendo por ejemplo de qué índices están definidos, cantidad
de tuplos en lo que hubiera sido el cursor exterior y el interior,
etc. Además el mantenimiento de la forma procedural será mucho mas
costoso y dara muchas mas posibilidades de introducir errores.
Los triggers son en realidad una forma de compensar por la
deficiencia en las posiblidades de expresar reglas de forma
declarativa en los productos que tenemos. Esta definciencia junto
con los domains (tipos) que nos traen estos productos son realmente
para morirse de risa.
Nota: Hacer en las aplicaciones lo que no se puede hacer
declarativamente en la bbdd es peor que hacerlo proceduralmente
en triggers. Entonces se introduce 'dependencia lógica de datos'.
(La estructura se fija en la aplicación)

Habiendo definido los constraints en la BBDD el SGBD podra acceptar
o rechazar las operaciones (insert/update/delete) dependiendo no
solo de los constraints definidos sino también del estado actual
de la BBDD. Si en un momento dado los datos son consistentes y las
reglas de integridad están bien definidas, se garantiza asi que
después de una operación lo sigan siendo (y que datos derivados sean
también consistentes naturalmente).
Esto, junto con la derivación de datos son las funciones principales
de un SGBD y no el 'persistir' o almacenar datos como piensan muchos.

Dicho de otra forma, se puede utilizar el SGBD para controlar todo
lo que "entra" (constrains declarados, triggers) y lo que "sale"
(views). Las tablas base no tienen por que ser accesibles, para asi
obligar al usuario (o aplicación) a acceder a los datos con la view;
eso si fuera necesario, claro. Desde el punto de vista del usuario
(o aplicación) no tendría por que diferenciarse una view de una
tabla base, y estas tendrían que ser intercambiables, pero bueno...
los SGBD's que tenemos son los que tenemos. (También de risa.)

Por muchas aplicaciones distintas que se conecten o usuarios con
distintas herramientas, hasta con ad hoc SQL directamente, entonces
el control de la integridad de los datos estará en manos del SGBD,
con las reglas de integridad definidas en la base de datos; un
control centralizado y compartido por multiplos usuarios y distintas
aplicaciones. Esa es un poco la idea en general.

== Views / Independencia lógica de datos =Las views son también un instrumento para consegir 'independencia
lógica de datos'. Imaginemos por ejemplo que tenemos dos datos que
son derivables uno del otro; si tenemos A puedemos calcular B y
viceversa. (Cálcular en el sintido mas amplio de la palabra: buscar
determinar,...) Entonces se define un view que ofrece A y B y mas
tarde se decide guardar A en una tabla base y calcular B, o al revés.
Se consiguen asi dos cosas, 1) A y B constituyen una interfaz que
encapsula una implementación (qué se guarda, qué se calcula y el
cálculo mismo) que siempre se podra cambiar por ejemplo por motivos
de eficiencia sin influir la funcionalidad de las aplicaciones;
y 2) el cálculo está centralizado y no habrá contradicciones como
cuando distintas aplicaciones hubieran hecho el cálculo ellas mismas,
cada una a 'su manera' (que puede ser un cálculo complicado).
Otro ejemplo sería que en el dominio de una aplicación un determinado
dato (o tabla) se llama X, en la otra se llama Y y en la base de datos
se conoze como Z. Con un view para cada aplicación, asunto
solucionado. Imaginemos también una combinación de los dos ejemplos
anteriores donde distintas aplicaciones quieren cosas distintas
(A o B) y además les dan otros nombres. Este es un mechanismo muy
potente por ejemplo a la hora de integrar dos sistemas.
En estos ejemplos los datos A y B podrían ser también tablas!

Por lo que se refiere a eficiencia imaginemos tener que derivar un
dato que necesita miles de tuplos de varias tablas para su cálculo.
Y de estos datos derivados necesitamos unos cuantos cientos. Una
cosa es pedirle estos datos deriavados al SGBD y otra es extraer
todos los tuplos de la bbdd necesarios para el cálculo y hacerlo por
ejemplo en la aplicación. Imagínense la diferencia en tráfico en una
red, por no hablar del rollo que se monta la aplicación para hacerlo.
Además cuando se desarrolle otra aplicación y esta también necesite
este dato (derivado o no, es un dato), se tendrá que 'inventar' de
nuevo el método de cálculo. Los desarrolladores no tenían ni por
que ser conscientes de que este dato es derivado si estubiera en la
bbdd. Al tener que derivarlo tampoco tienen por que ser conscientes
de que el método de cálculo ya está 'inventado' y aunque lo fueran
quizás no sea posible acceder al código para copiar; que a su vez
si fuera posible sería una tontería. Mejor tenerlo centralizado y
compartido. Otra forma de verlo es pensar que la integridad de este
dato derivado no estaría bajo control del SGBD y no se podría
garantizar. Por ser un dato derivado 'no se es menos dato' y no
significa eso que no tenga que ser controlado por el SGBD.
Por razones p.e. de eficiencia de aplicaciones mas 'importantes'
hoy es calculado y mañana puede que no.

== Analogía con la OO =En términos de OO se puede ver el sistema completo como organizado en
un patrón MVC (model-view-controller). El modelo es la DDBB misma,
el controlador es el SGBD ayudado por las reglas (constraints,
views, etc.) en la BBDD, y las vistas del MVC son las aplicaciones
(que pueden ser varias y 'muy diferentes'). La interfaz entre
aplicaciones (vistas en MVC) y el SGBD (controlador) es SQL (o en
general el lenguage de acceso) y las "partes públicas" de la
definición de la BBDD. Como el modelo/controlador implementen esta
interfaz no es asunto de las aplicaciones (eso debe estar
encapsulado). El estado actual del modelo (BBDD) y el controlador
(SGBD) determinan juntos lo que aceptan o no para mantener el modelo
en un estado consistente, digan lo que digan las vistas
(aplicaciones). Lo que son "partes públicas" (interfaz) depende
también de quien acceda a la base de datos (distintos 'roles').
Distintas aplicaciones o grupos de aplicaciones pueden tener 'vistas'
(percepciones: otras views, otras tablas, otros ...) distintas de
que es lo que ofrece la BBDD.


== Teoría =La base para todo esto es el modelo relacional, que a su vez es una
aplicación matemática de la lógica de predicados y teoría de
conjuntos.

En algunos casos cuando se habla de datos en realidad se está
hablando de 'hechos' o formalmente "proposiciones de las que se sabe
que son ciertas", o sea su valor booleano es 'Verdadero' (True).
Proposicones que no están registradas en la BBDD son considerados
'Falsas', o sea que no son hechos. Esto es lo que se llama 'Closed
world assumption' que hace posible considerar un SGBD como un motor
de deducción lógica de 'hechos' en el dominio para el que se ha
diseñado la BBDD.

== Cuidado! =Suele haber mucha discusión por no enterder bien lo que es la
'independencia de datos' para no hablar de la distinción entre
independencia lógica y físical!

Cuidado también con esto: Tratar de explicar esto aqui tiene que
resultar casi necesariamente en un churro fragmentado, incompleto y
retorcido. Son demasiados conceptos en un texto 'demasiado corto' y
que necesita mucha mas estructura. Cada concepto podría llenar
paginas en un libro, que para eso están.

Si se entiende todo esto, se entiende también por qué las bbdd XML
son una barbaridad, por qué ORM tools son snake-oil (aceite de
serpiente) y por qué la gestión de datos no se debe hacer en las
aplicaciones, con o sin OO. Son los temas clásicos que dan lugar a
discusiones muy acaloradas en varios grupos. En el trabajo mejor
ya ni mencionarlo porque en menos de nada te ponen en la hogera.
Ayuda también a entender todo esto si se profundiza también en la
historia del asunto. Qué es lo que pasaba, que ha llevado a alguno
a investigar para finalmente venir con el modelo relacional. Qué
problemas trababa de solucionar en la forma de como se trabajaba
antes? (A la que muchos parecen estar muy ansiosos por volver,
o nunca han dejado.)

Ahora paro que ya está bién! No se si es posible que esto le aclare
algo a alguien que no esté familiarizado ya con el asunto.Por
expericencia diría que no. Solo he tocado un poco algunos conceptos
y dado un par de ejemplos mas bien simplones que podrían levar a
alguien, con la menten aún abierta, a hacerse preguntas.
Si soy sincero... no creo que haya valido la pena haber escrito
todo esto, pero ya he llegado hasta aquí.

== Y la necesaria referencia =Lo mejor es leer esto:
http://www.amazon.com/Introduction-...0321197844
Alfredo ha dado varias veces referencias a la séptima edición en
español,
pero parece que a la gente no le gusta la lectura y prefiere recetas
de métodos que simplemente 'trabajan'.

Saludos,
Carlos