Factura, líneas de facturas, artículo

Hola Daniel,

On Wed, 22 Nov 2006 12:56:21 -0300, "Daniel Ruzo"
wrote:

Mi opinión es que únicamente el SGBD debe encargarse de administrar la
integridad de los datos

Estamos de acuerdo en lo fundamental.

y las clases serían buenas herramientas para
trabajar con esos datos.

¿Pero a que llamas trabajar con los datos?

Todo lo que se necesita hacer con los datos al final se reduce a
asegurar su integridad y derivar nuevos datos. Los SGBD son lo mejor
para esto y no el código de aplicación procedimental.


Saludos
Alfredo

Totalmente de acuedo.

Voy a intentar a explicarme de nuevo.

La pregunta que realice, era para ver el enfoque que emplea la gente para
responder a problemáticas de ese estilo. Se que hay diversas formas de
hacerlo, quisiera estudiarlas. Me explico:

Tenemos una factura con sus líneas, y estas, tienen información referente a
artículos para obtener sus datos como código, descripción, precio. Si las
líneas referencian al artículo podemos tener ciertos dilemas.

Los dilemas:

- Un día determinado, cambiamos el precio de un artículo. Las facturas
hasta ahora realizadas en el sistema se verán envueltas en el cambio porque
sus líneas reflejarán el cambio, nos mostrarán el nuevo precio del artículo.
Si bien en otros casos esto puede ser beneficioso, en este caso no lo es
porque por Ley, las facturas se deben de mantener invariables.

- Lo mismo sucede si cambiamos otra información como puede ser la
descripción, el código, etc.

- Borramos un artículo. Las líneas que hacían referencia a ese artículo,
pierden dicha información.

Se ha comentado que la integridad de los datos debería de gestionarlos la
base de datos. Mi duda es la siguiente: Si bien podemos mantener el tipo de
integridad referencial para actualizar los datos en cascada y podemos
eliminar en cascada los registros relacionados, creo que nada de esto es
aplicable a nuestro caso, es decir, el cambio de la clave foranea no se
daría, porque por cuestiones de mapeo de objetos en una bd relacionar,
pensaba utilizar un código Guid para cada objeto, invariable en toda su
vida. Tampoco es necesario (ni deseado) el borrado de las líneas por el
hecho de borrar un artículo (borrado en cascada), entonces, pregunto:

¿ es posible mediante la Base de datos evitar el borrado de un elemento (en
nuestro caso un artículo) si sabemos que se utiliza en alguna línea?

y

¿ La forma de controlarlo se puede aplicar en la mayoría de las base de
datos ?. Es dificil portar esa "logica" de una a otra ?

y para los casos de cambio de precio, descripción, etc. ¿ Qué planteamiento
optarían ?, ¿ Copiar estos valores en a línea?. Con ello duplicamos
información..., etc.

Muchas Gracias por vuestro tiempo.
Bix





"Daniel Ruzo" escribió en el mensaje
news:

Bingen:

Creo que la discusión nació interesante pero se ha desvirtuado por las
controversias.

No estoy de acuerdo con Alfredo en cuanto a que tener una clase de ese
tipo no aporta nada. Pero creo que tú creas la confusión al hablar de las
restricciones (no poder borrar un artículo que está referenciado en una
factura, por ejemplo) cuando estás hablando de la clase.

Mi opinión es que únicamente el SGBD debe encargarse de administrar la
integridad de los datos y las clases serían buenas herramientas para
trabajar con esos datos.

¡Saludos!

*****************************************************
Daniel Ruzo
Miembro del GCU (Grupo Clarion Uruguay)
*****************************************************
"Bingen" escribió en el mensaje
news:eJpJ%

Hola Alfredo:

SQL es un lenguaje con mucho mayor nivel de abstracción que C#.

Te suena la herencia y el polimorfismo, etc... Qué nivel de
abstracción tiene una tabla de cliente (campos de tipos de la base de
datos) respecto a una clase de cliente en la que englobamos en ella
podemos englobar información de tipos dispares (hasta propios)

Intentar abstraer una tabla SQL con construcciones C# tiene aun menos
sentido que intentar abstraer código C# usando ensamblador.

Yo parto de la manera inversa, primeramente se estudia el problema
(modelo conceptual, de diseño, etc) y luego determinamos que clases deben
ser persistentes, en una BD, etc..

Crear un sistema de información mínimamente complejo sin utilizar un
SGBD es un disparate.

¿ Quien a dicho lo contrario ?

Tu pregunta se centraba sobre la lógica de datos. En un sistema de
información la lógica de aplicaciones debe de ser solamente la lógica
de presentación y comunicación. La suma de todos estos tipos de lógica
forma la lógica del sistema (de información).

Podría existir una capa de lógica de presentación, una de lógica de
negocio, una de persistencia de datos, otra de datos (un proveedor de bd,
ficheros planos, XML, etc)

Mi pregunta se centraba en el
diseño de la lógica y objetos para solucionar estas cuestiones:

- Si relacionamos una línea de factura y artículo, que pasa si (el
usuario desea borrar un articulo, el usuario modifica el precio, el
usuario
modifica la descripción del artículo, etc.). Lo que sucede es que la
factura
se modifica, es decir, que si cambiasemos por ejemplo un artículo, por
ejemplo "Lapicero", cambiamos su descripción por "Bolígrafo" y su pecio
de 1
euro por dos. Todas aquellas facturas en el sistema que tengan líneas
relacionadas con este artículo se cambiarían, cosa no deseada, porque
las
facturas se tienen que mantener invariables.

Esto es sin ningunar duda lógica de base de datos, por lo tanto debe
de quedar fuera de las aplicaciones.

Todo esto es trivial si usas un SGBD.

¿ Si ?, eso quiero, respuestas, porque por eso pido vuestra opinión, pero
Alfredo, seamos más explicitos.

La solución que ahora pienso diseñar es la siguiente, haber que les
parece:

- Crear una clase Artículo con su código, precio, descripción, etc.
- Crear una clase llamada ArticuloLínea que heredará toda la
funcionalidad
de Artículo. Lo que variará de Articulo es su lógica de almacenamiento
de
sus datos para almacenar estos en otra tabla o donde sea.
-Crear una clase Línea que asociaremos a ArtículoLínea. Ahora al asociar
un
artículo a la línea, copiaremos toda su información al artículolínea
relacionado con la línea, así cualquier modificación en el Artículo no
afectará a la información de la línea.

- Lo mismo podría realizarse con la relación de la clase Cliente con la
clase factura. Podríamos crear la clase ClienteFactura y copiar aquí la
información de cliente y relacionar esta clase con la factura. Así
futuras
modificaciones del cliente no afectarian a la información de la cabecera
de
la factura.

¿Que les parece ?

Que viola casi todos los principios de diseño de sistemas de
información.

¿ Esta mal ?, Semos más explicitos.

Un saludo y gracias por tu tiempo
Bix




"Alfredo Novoa" escribió en el mensaje
news:

Hola,

On Mon, 20 Nov 2006 17:08:01 +0100, "Bingen"
wrote:

Si bien lo que tu me comentas es correcto en cuanto a bases de datos,
mi
inquietud era en cuanto una mayor abstracción de los conceptos Factura.

SQL es un lenguaje con mucho mayor nivel de abstracción que C#.

Intentar abstraer una tabla SQL con construcciones C# tiene aun menos
sentido que intentar abstraer código C# usando ensamblador.

Si bien es correcto que se pueden almacernar en una base de datos, no
menos
cierto es que podría almacenar las facturas en otros medios (XML, etc)

Una base de datos es un conjunto de datos independientemente de como
se gestione. Si tienes una base de datos guardada en un archivo XML
sigue siendo una base de datos.

Crear un sistema de información mínimamente complejo sin utilizar un
SGBD es un disparate.

En cuanto a la abstracción, lo que pregunto tiene MUCHO que ver con UML
y
POO, es decir, en mi pregunta se centraba en la lógica de la aplicación

Tu pregunta se centraba sobre la lógica de datos. En un sistema de
información la lógica de aplicaciones debe de ser solamente la lógica
de presentación y comunicación. La suma de todos estos tipos de lógica
forma la lógica del sistema (de información).

dejando de forma secundaria su almacenamiento.

El almacenamiento no tiene nada que ver con la lógica de datos.

Mi pregunta se centraba en el
diseño de la lógica y objetos para solucionar estas cuestiones:

- Si relacionamos una línea de factura y artículo, que pasa si (el
usuario desea borrar un articulo, el usuario modifica el precio, el
usuario
modifica la descripción del artículo, etc.). Lo que sucede es que la
factura
se modifica, es decir, que si cambiasemos por ejemplo un artículo, por
ejemplo "Lapicero", cambiamos su descripción por "Bolígrafo" y su pecio
de 1
euro por dos. Todas aquellas facturas en el sistema que tengan líneas
relacionadas con este artículo se cambiarían, cosa no deseada, porque
las
facturas se tienen que mantener invariables.

Esto es sin ningunar duda lógica de base de datos, por lo tanto debe
de quedar fuera de las aplicaciones.

Todo esto es trivial si usas un SGBD.

La solución que ahora pienso diseñar es la siguiente, haber que les
parece:

- Crear una clase Artículo con su código, precio, descripción, etc.
- Crear una clase llamada ArticuloLínea que heredará toda la
funcionalidad
de Artículo. Lo que variará de Articulo es su lógica de almacenamiento
de
sus datos para almacenar estos en otra tabla o donde sea.
-Crear una clase Línea que asociaremos a ArtículoLínea. Ahora al asociar
un
artículo a la línea, copiaremos toda su información al artículolínea
relacionado con la línea, así cualquier modificación en el Artículo no
afectará a la información de la línea.

- Lo mismo podría realizarse con la relación de la clase Cliente con la
clase factura. Podríamos crear la clase ClienteFactura y copiar aquí la
información de cliente y relacionar esta clase con la factura. Así
futuras
modificaciones del cliente no afectarian a la información de la cabecera
de
la factura.

¿Que les parece ?

Que viola casi todos los principios de diseño de sistemas de
información.


Saludos
Alfredo

Totalmente de acuedo.

Voy a intentar a explicarme de nuevo.

La pregunta que realice, era para ver el enfoque que emplea la gente para
responder a problemáticas de ese estilo. Se que hay diversas formas de
hacerlo, quisiera estudiarlas. Me explico:

Tenemos una factura con sus líneas, y estas, tienen información referente a
artículos para obtener sus datos como código, descripción, precio. Si las
líneas referencian al artículo podemos tener ciertos dilemas.

Los dilemas:

- Un día determinado, cambiamos el precio de un artículo. Las facturas
hasta ahora realizadas en el sistema se verán envueltas en el cambio porque
sus líneas reflejarán el cambio, nos mostrarán el nuevo precio del artículo.
Si bien en otros casos esto puede ser beneficioso, en este caso no lo es
porque por Ley, las facturas se deben de mantener invariables.

- Lo mismo sucede si cambiamos otra información como puede ser la
descripción, el código, etc.

- Borramos un artículo. Las líneas que hacían referencia a ese artículo,
pierden dicha información.

Se ha comentado que la integridad de los datos debería de gestionarlos la
base de datos. Mi duda es la siguiente: Si bien podemos mantener el tipo de
integridad referencial para actualizar los datos en cascada y podemos
eliminar en cascada los registros relacionados, creo que nada de esto es
aplicable a nuestro caso, es decir, el cambio de la clave foranea no se
daría, porque por cuestiones de mapeo de objetos en una bd relacionar,
pensaba utilizar un código Guid para cada objeto, invariable en toda su
vida. Tampoco es necesario (ni deseado) el borrado de las líneas por el
hecho de borrar un artículo (borrado en cascada), entonces, pregunto:

¿ es posible mediante la Base de datos evitar el borrado de un elemento (en
nuestro caso un artículo) si sabemos que se utiliza en alguna línea?

y

¿ La forma de controlarlo se puede aplicar en la mayoría de las base de
datos ?. Es dificil portar esa "logica" de una a otra ?

y para los casos de cambio de precio, descripción, etc. ¿ Qué planteamiento
optarían ?, ¿ Copiar estos valores en a línea?. Con ello duplicamos
información..., etc.

Muchas Gracias por vuestro tiempo.
Bix

"Daniel Ruzo" escribió en el mensaje
news:

Bingen:

Creo que la discusión nació interesante pero se ha desvirtuado por las
controversias.

No estoy de acuerdo con Alfredo en cuanto a que tener una clase de ese
tipo no aporta nada. Pero creo que tú creas la confusión al hablar de las
restricciones (no poder borrar un artículo que está referenciado en una
factura, por ejemplo) cuando estás hablando de la clase.

Mi opinión es que únicamente el SGBD debe encargarse de administrar la
integridad de los datos y las clases serían buenas herramientas para
trabajar con esos datos.

¡Saludos!

*****************************************************
Daniel Ruzo
Miembro del GCU (Grupo Clarion Uruguay)
*****************************************************
"Bingen" escribió en el mensaje
news:eJpJ%

Hola Alfredo:

SQL es un lenguaje con mucho mayor nivel de abstracción que C#.

Te suena la herencia y el polimorfismo, etc... Qué nivel de
abstracción tiene una tabla de cliente (campos de tipos de la base de
datos) respecto a una clase de cliente en la que englobamos en ella
podemos englobar información de tipos dispares (hasta propios)

Intentar abstraer una tabla SQL con construcciones C# tiene aun menos
sentido que intentar abstraer código C# usando ensamblador.

Yo parto de la manera inversa, primeramente se estudia el problema
(modelo conceptual, de diseño, etc) y luego determinamos que clases deben
ser persistentes, en una BD, etc..

Crear un sistema de información mínimamente complejo sin utilizar un
SGBD es un disparate.

¿ Quien a dicho lo contrario ?

Tu pregunta se centraba sobre la lógica de datos. En un sistema de
información la lógica de aplicaciones debe de ser solamente la lógica
de presentación y comunicación. La suma de todos estos tipos de lógica
forma la lógica del sistema (de información).

Podría existir una capa de lógica de presentación, una de lógica de
negocio, una de persistencia de datos, otra de datos (un proveedor de bd,
ficheros planos, XML, etc)

Mi pregunta se centraba en el
diseño de la lógica y objetos para solucionar estas cuestiones:

- Si relacionamos una línea de factura y artículo, que pasa si (el
usuario desea borrar un articulo, el usuario modifica el precio, el
usuario
modifica la descripción del artículo, etc.). Lo que sucede es que la
factura
se modifica, es decir, que si cambiasemos por ejemplo un artículo, por
ejemplo "Lapicero", cambiamos su descripción por "Bolígrafo" y su pecio
de 1
euro por dos. Todas aquellas facturas en el sistema que tengan líneas
relacionadas con este artículo se cambiarían, cosa no deseada, porque
las
facturas se tienen que mantener invariables.

Esto es sin ningunar duda lógica de base de datos, por lo tanto debe
de quedar fuera de las aplicaciones.

Todo esto es trivial si usas un SGBD.

¿ Si ?, eso quiero, respuestas, porque por eso pido vuestra opinión, pero
Alfredo, seamos más explicitos.

La solución que ahora pienso diseñar es la siguiente, haber que les
parece:

- Crear una clase Artículo con su código, precio, descripción, etc.
- Crear una clase llamada ArticuloLínea que heredará toda la
funcionalidad
de Artículo. Lo que variará de Articulo es su lógica de almacenamiento
de
sus datos para almacenar estos en otra tabla o donde sea.
-Crear una clase Línea que asociaremos a ArtículoLínea. Ahora al asociar
un
artículo a la línea, copiaremos toda su información al artículolínea
relacionado con la línea, así cualquier modificación en el Artículo no
afectará a la información de la línea.

- Lo mismo podría realizarse con la relación de la clase Cliente con la
clase factura. Podríamos crear la clase ClienteFactura y copiar aquí la
información de cliente y relacionar esta clase con la factura. Así
futuras
modificaciones del cliente no afectarian a la información de la cabecera
de
la factura.

¿Que les parece ?

Que viola casi todos los principios de diseño de sistemas de
información.

¿ Esta mal ?, Semos más explicitos.

Un saludo y gracias por tu tiempo
Bix




"Alfredo Novoa" escribió en el mensaje
news:

Hola,

On Mon, 20 Nov 2006 17:08:01 +0100, "Bingen"
wrote:

Si bien lo que tu me comentas es correcto en cuanto a bases de datos,
mi
inquietud era en cuanto una mayor abstracción de los conceptos Factura.

SQL es un lenguaje con mucho mayor nivel de abstracción que C#.

Intentar abstraer una tabla SQL con construcciones C# tiene aun menos
sentido que intentar abstraer código C# usando ensamblador.

Si bien es correcto que se pueden almacernar en una base de datos, no
menos
cierto es que podría almacenar las facturas en otros medios (XML, etc)

Una base de datos es un conjunto de datos independientemente de como
se gestione. Si tienes una base de datos guardada en un archivo XML
sigue siendo una base de datos.

Crear un sistema de información mínimamente complejo sin utilizar un
SGBD es un disparate.

En cuanto a la abstracción, lo que pregunto tiene MUCHO que ver con UML
y
POO, es decir, en mi pregunta se centraba en la lógica de la aplicación

Tu pregunta se centraba sobre la lógica de datos. En un sistema de
información la lógica de aplicaciones debe de ser solamente la lógica
de presentación y comunicación. La suma de todos estos tipos de lógica
forma la lógica del sistema (de información).

dejando de forma secundaria su almacenamiento.

El almacenamiento no tiene nada que ver con la lógica de datos.

Mi pregunta se centraba en el
diseño de la lógica y objetos para solucionar estas cuestiones:

- Si relacionamos una línea de factura y artículo, que pasa si (el
usuario desea borrar un articulo, el usuario modifica el precio, el
usuario
modifica la descripción del artículo, etc.). Lo que sucede es que la
factura
se modifica, es decir, que si cambiasemos por ejemplo un artículo, por
ejemplo "Lapicero", cambiamos su descripción por "Bolígrafo" y su pecio
de 1
euro por dos. Todas aquellas facturas en el sistema que tengan líneas
relacionadas con este artículo se cambiarían, cosa no deseada, porque
las
facturas se tienen que mantener invariables.

Esto es sin ningunar duda lógica de base de datos, por lo tanto debe
de quedar fuera de las aplicaciones.

Todo esto es trivial si usas un SGBD.

La solución que ahora pienso diseñar es la siguiente, haber que les
parece:

- Crear una clase Artículo con su código, precio, descripción, etc.
- Crear una clase llamada ArticuloLínea que heredará toda la
funcionalidad
de Artículo. Lo que variará de Articulo es su lógica de almacenamiento
de
sus datos para almacenar estos en otra tabla o donde sea.
-Crear una clase Línea que asociaremos a ArtículoLínea. Ahora al asociar
un
artículo a la línea, copiaremos toda su información al artículolínea
relacionado con la línea, así cualquier modificación en el Artículo no
afectará a la información de la línea.

- Lo mismo podría realizarse con la relación de la clase Cliente con la
clase factura. Podríamos crear la clase ClienteFactura y copiar aquí la
información de cliente y relacionar esta clase con la factura. Así
futuras
modificaciones del cliente no afectarian a la información de la cabecera
de
la factura.

¿Que les parece ?

Que viola casi todos los principios de diseño de sistemas de
información.


Saludos
Alfredo

Todo eso que mencionas lo tiene que manejar el motor o tu diseño de la base
de datos. En este sentido, tenía razón Alfredo.

- Un día determinado, cambiamos el precio de un artículo. Las facturas
hasta ahora realizadas en el sistema se verán envueltas en el cambio
porque
sus líneas reflejarán el cambio, nos mostrarán el nuevo precio del
artículo.
Si bien en otros casos esto puede ser beneficioso, en este caso no lo es
porque por Ley, las facturas se deben de mantener invariables.

Esto es un tema de diseño. Hagamos un análisis de datos. Si bien en el
momento de facturar tomas el precio vigente de la lista de precios, ese
precio es un dato "diferente" del precio vigente. No es el "precio de venta
vigente" sino el "precio de venta vigente en el momento de la venta". El
precio vigente cambia con el tiempo y depende del producto; el de la factura
se mantiene constante y depende de la factura. Por lo tanto, debes tener una
columna para precio de venta en la tabla de lineas de factura (y demás
documentos).

- Lo mismo sucede si cambiamos otra información como puede ser la
descripción, el código, etc.

En cuanto a la descripción, si bien podría darse el caso de que cambien un
artículo por otro a través del nombre y sigan usando el mismo número de
artículo para un artículo diferente, sería un problema de "uso" de la
aplicación y no de la aplicación en sí. En la práctica no se da, y la
descripción del artículo no se registra en la tabla de lineas de factura.
Nuestra entidad "articulo" se mantiene constante a través de su
identificación, y si el usuario cambia la descripción no es un problema
nuestro. El artículo que ayer se llamaba "A" ahora se llama "B", pero para
la base de datos sigue siendo el mismo artículo que cambió un atributo. Si
ayer vendí el artículo 1 que se llamaba "A", hoy digo que vendí el artículo
1 que se llama "B". Y siempre se puede recurrir al documento impreso para
ver la descripción de aquel momento. Si fuera una cuestión fundamental tener
en la base de datos el nombre exacto utilizado en determinado momento se
debería considerar en el diseño y tener una tabla de cambios históricos, en
la cual se establezca que hasta tal fecha/hora el nombre del artículo tuvo
tal valor.

Respecto al código, si es lo que se utiliza como identifiación del artículo
(clave primaria) para mi gusto no debería permitirse cambiar. Pero reitero
que es una cuestión de gusto. Si se decide que se permite cambiar debería
establecerse en el motor de base de datos que se propague en cascada ese
cambio a todas las tablas relacionadas mediante "UPDATE CASCADE". Y si se
decide que la clave primaria no se pueda modificar la restricción debe ser
del tipo "UPDATE RESTRICT".

- Borramos un artículo. Las líneas que hacían referencia a ese
artículo,
pierden dicha información.

Esto lo solucionas con una restricción de tipo "DELETE RESTRICT". Si la
clave primaria está referenciada en otra tabla no se puede eliminar.

Se ha comentado que la integridad de los datos debería de gestionarlos la
base de datos. Mi duda es la siguiente: Si bien podemos mantener el tipo
de
integridad referencial para actualizar los datos en cascada y podemos
eliminar en cascada los registros relacionados, creo que nada de esto es
aplicable a nuestro caso, es decir, el cambio de la clave foranea no se
daría, porque por cuestiones de mapeo de objetos en una bd relacionar,
pensaba utilizar un código Guid para cada objeto, invariable en toda su
vida. Tampoco es necesario (ni deseado) el borrado de las líneas por el
hecho de borrar un artículo (borrado en cascada), entonces, pregunto:

¿ es posible mediante la Base de datos evitar el borrado de un elemento
(en
nuestro caso un artículo) si sabemos que se utiliza en alguna línea?

Por lo que veo, tus dudas surgen de que conoces las restricciones "CASCADE"
pero no las "RESTRICT". Así que está respondido más arriba.

Las restricciones de tipo "CASCADE" se deberían usar en casos muy
delimitados, como por ejemplo para borrar un cabezal de factura y todas sus
lineas. Pero por lo general se utiliza "RESTRICT" para no perder
información. Pero depende de cada caso en particular.

¿ La forma de controlarlo se puede aplicar en la mayoría de las base de
datos ?. Es dificil portar esa "logica" de una a otra ?

Sí, las restricciones son un estándar. Algunos motores no soportan el
"CASCADE", pero la mayoría soporta ambos tipos de restricción.

y para los casos de cambio de precio, descripción, etc. ¿ Qué
planteamiento
optarían ?, ¿ Copiar estos valores en a línea?. Con ello duplicamos
información..., etc.

Esto ya lo comenté más arriba. No se duplica información cuando se trata de
datos diferentes. El precio de una factura es diferente al precio vigente,
pero la descripción del artículo es el mismo dato siempre, aunque cambie.

¡Saludos!

*****************************************************
Daniel Ruzo
Miembro del GCU (Grupo Clarion Uruguay)
*****************************************************

¿Pero a que llamas trabajar con los datos?


Todo lo que se necesita hacer con los datos al final se reduce a
asegurar su integridad y derivar nuevos datos. Los SGBD son lo mejor
para esto y no el código de aplicación procedimental.

Sí, para segurar la integridad lo mejor son los SGBD. Pero los datos se
registran, se recuperan, se presenten (muestran), se procesan para obtener
otros datos, etc., etc.

Si bien veo que Bingen apuntaba a otra cosa de todos modos surgió el tema de
las clases y pienso que pueden tener sus ventajas. Intentaré presentar un
ejemplo.

Tengo una clase que crea el objeto "transacción". Este objeto tiene un
método "leer" que se encarga de leer el cabezal de la transacción y todas
sus lineas. Con una simple invocación a este método cargo toda la
transacción en el objeto. También existe un método "calcularTotal" que suma
los importes de las lineas de la transacción y devuelve el total. Otro
método podría ser "estaVencida" que evalúe la fecha de vencimiento con la
fecha actual.

A partir de este objeto "transacción" yo puedo derivar un objeto "factura de
venta", otro "factura de compra", etc. Si bien la lectura y la grabación
deberán ser diferentes, el cálculo del total será el mismo y también
compartirán el control de documento vencido. Y como mencionaba Bingen, las
referencias a los artículos de cada linea podrían ser a un objeto, lo mismo
que las referencias al cliente o proveedor. Cuidado que no hablo de la base
de datos, sino a nivel del objeto en memoria. La base de datos estaría en
una capa inferior con la que sólo se comunicarían algunos métodos de las
clases. También podría haber una capa superior que se encargue de
interactuar con el usuario.

Se que para la forma de pensar habitual suena a loco, pero para grandes
proyectos podría ser una buena manera de encarar las cosas. Y ni que hablar
de la portabilidad que tendría el desarrollo, puesto que las clases serían
independientes de la aplicación.

¡Saludos!

*****************************************************
Daniel Ruzo
Miembro del GCU (Grupo Clarion Uruguay)
*****************************************************