Espacios de Nombres

On Tue, 9 Nov 2004 10:31:54 +0100, "Octavio Hernandez"
wrote:

¿No estás a favor de la representación de las entidades que resultan del
diseño mediante clases, no?

Creo que aquí hay una confusión muy generalizada. Un cliente o un
conjunto de clientes es una entidad, y el conjunto de propiedades que
representan a un cliente en un modelo conceptual se llama "tipo de
entidad".

Cuando creamos un diseño lógico a partir de un diseño conceptual, cada
tipo de entidad se corresponde con la cabecera de una o varias
variables relacionales (vulgarmente llamadas tablas).

Una tabla (cuanto tabla significa variable), no es más que una
VARIABLE de tipo colección, igual que una variable de tipo "array".

Nada que ver con una clase (en el contexto de un lenguaje OO), que es
un TIPO escalar (es decir que no es de tipo colección).

Desgraciadamente la mayoría de los lenguajes de programación no
permiten definir variables de tipo relación, y no podemos representar
fácilmente las "tablas" de la base de datos en las aplicaciones. A
esto se le llama "object-relational mismatch".

La verdad es que yo no lo tengo muy claro,
ciertas cosas que he visto en el mundo Java me han llegado a parecer
verdaderas aberraciones...

Yo tengo muy claro que en mundo Java se suelen cometer muchas
aberraciones.

Pero de una manera muy intuitiva, sería natural
pensar que si la aplicación manipula clientes, debe haber una clase Cliente,
¿no?

Totalmente de acuerdo, pero ninguna aplicación moderna debe de
manipular clientes, eso se debe de dejar al SGBD.

Si no usasemos un SGBD y manipulasemos la base de datos directamente
desde la aplicación pues lo lógico sería que hubiese una clase
Cliente.

Pero cuando usamos un SGBD la cosa cambia completamente y mucha gente
no se da cuenta por falta de formación en teoría de bases de datos.

Quien manipula los clientes es el SGBD y la aplicación lo que debe de
hacer es traducir las acciones del usuario (pulsación de botones, etc)
en instrucciones para el SGBD (SQL), y mostrar los resultados. Y para
esto ya no necesitamos la clase Cliente.

Lo que hace mucha gente es crear aplicaciones como se hacía antes de
que existiesen los SGBD (con la clase Cliente), y utilizar al SGBD
como un mero gestor de ficheros transaccional, desaprovechando casi
toda su potencia, y esto es una de las aberraciones de las que
hablábamos.

Esto es un tema bastante desesperante, por que la mayoría de los
programadores se montan unos lios tremendos con la integración de las
aplicaciones y los SGBD.

Hace poco alguien publicó en este grupo un enlace a un artículo en el
que Heljsberg mostraba una profundísima ignorancia sobre el tema.


Saludos