Campo dependiente de otros campos en varias tablas

Perdónenme Vds. por no haber contestado, es que este hilo lo estaba
siguiendo en otro ordenatriz y (vayaustéasaberporqué) me mezcla los post y
se come algún que otro mensaje.

Estas cosas se entienden con bastante facilidad si vamos al modelo Entidad
Relación y establecemos que las entidades Clientes y Proveedores son
entidades de bajo nivel y la entidad Titular es una entidad de alto nivel
resultado de la generalización de ambas. Es lo que se llama una realación
IS-A (es un).

Partiendo de esto, relacionamos la entidad Pagos con la entidad Titulares.
Un titular puede ser un Cliente o un Proveedor. Amo a vé si yo puedo dibujar
esto con palitos y bolitas :)

Pagos -- (Otras entidades)
|
Titular
|
IS-A
/\
/ \
Cliente Proveedor

¿Cómo representar esto en nuestro modelo de tablas? Evidentemente no vamos a
crear una nueva tabla Titulares, añadiremos un nuevo campo en la tabla pagos
que, junto con el campo Titular, nos permitirá localizar sin problemas el
titular. Ejemplo que se entiende mejor:

Pagos:
IdPago
Blablabla
TipoTitular
Titular

El campo TipoTitular nos dirá si es un cliente (C) o un proveedor (P).
En el campo Titular guardaremos el código de cliente o de proveedor.
Partiendo de la tabla Pagos, con los campos TipoTitular y Titular podemos
localizar el Titular en la tabla que le corresponda.

Oki, ahora ¿cómo representar esto en un formulario? Mediante combos
dependientes.

Crearemos un combo para elegir el TipoTitular. De este combo dependerá el
combo Titulares, que modificará su origen de datos cuando se modifique el
TipoTitular. Es decir, si yo elijo en el combo Titular el tipo "Cliente",
automáticamente se me modificará el origen de datos del combo Titular para
presentarme todos los clientes de mi tabla. Al implementarlo veréis que hay
que hacer alguna cosita más para mantener la consistencia, como por ejemplo
cuando un tipo y código ya esté elegido y el usuario cambie el tipo a
posteriori, nos quedaremos en un estado inconsistente. Ejemplo:

El usuario elige tipo Clientes
El usuario elige un Cliente
El usuario elige Proveedores ¡¡¡¡!!!!!

En la tabla Pagos quedará Tipo Proveedor con un código perteneciente a un
Cliente. Inconsistencia al canto, nuestra base de datos hecha unos zorros,
bronca del cliente, arreglito por el morro y sofocón. Precaución a tomar: Al
cambiar en el combo Tipo, si el estado actual es diferente al anterior,
borrar el código de Titular. Y de estas, unas cuantas.

En este ejemplo la generalización solo atañe a dos tablas, pero podrían ser
más. El siguiente problema que se presenta es a la hora de listar los pagos,
en un informe, por ejemplo. Habrá que montar una consulta que muestre los
datos correctos sacándolos de las tablas correctas. Para ello hay que jugar,
de nuevo, con los dos campos.

En la dire http://fca.unl.edu.ar/agromatica/ag...unteER.doc hay
una explicación bastante clarita de generalización y especialización.

Espero que el rollo os sirva de ayuda :)
Eva Etxebeste
[MS MVP]

"julian-vlc-sp" <ijulianARROBAiespana.es> escribió en el mensaje
news:%

Puedes explicarte un poco más?

Esta claro que puedo hacer dos combos, uno par clientes y otro para
proveedores, y seleccionar uno, y poner el id en titular, pero luego, como
se a que tabla pertenece?, seria necesario un campo mas para indicar de

que

tabla he cogido el id?

Yo pensaba en hacer una unica tabla que fuese titulares, en lugar de las

dos

de clientes y proveedores, e implementar un campo donde le digo si es
cliente o proveedor (por ejemplo)

De esta forma, al tener un id en la tabla pagos, siempre se donde ir a
buscarlo (a la tabla titulares)

Este caso se me ha presentado varias veces, por ejmplo, varias tablas de
personas, operarios, clientes, proveedores, etc. segun en que

aplicaciones,

no es problema, cada tabla la uso para una cosa, por ejemplo para nominas
solo uso operarios, para cobros solo clientes, etc, pero en otras

ocasiones,

quisiera poder poner id de una persona de cualquier tabla, por ejemplo

para

las felicitaciones de navidad (aprovechando que cada vez estamos mas

cerca)

(Ni te cuento como lo he resuelto, lo dejo para el merengue).

SALUDOS MIL (guapetona)
julian-valencia-españa

Magistral Dra. Etxebeste


"Eva Etxebeste" <eetxebesteARROBAhotmail.com> escribió en el mensaje
news:

Perdónenme Vds. por no haber contestado, es que este hilo lo estaba
siguiendo en otro ordenatriz y (vayaustéasaberporqué) me mezcla los post y
se come algún que otro mensaje.

Estas cosas se entienden con bastante facilidad si vamos al modelo Entidad
Relación y establecemos que las entidades Clientes y Proveedores son
entidades de bajo nivel y la entidad Titular es una entidad de alto nivel
resultado de la generalización de ambas. Es lo que se llama una realación
IS-A (es un).

Partiendo de esto, relacionamos la entidad Pagos con la entidad Titulares.
Un titular puede ser un Cliente o un Proveedor. Amo a vé si yo puedo

dibujar

esto con palitos y bolitas :)

Pagos -- (Otras entidades)
|
Titular
|
IS-A
/\
/ \
Cliente Proveedor

¿Cómo representar esto en nuestro modelo de tablas? Evidentemente no vamos

a

crear una nueva tabla Titulares, añadiremos un nuevo campo en la tabla

pagos

que, junto con el campo Titular, nos permitirá localizar sin problemas el
titular. Ejemplo que se entiende mejor:

Pagos:
IdPago
Blablabla
TipoTitular
Titular

El campo TipoTitular nos dirá si es un cliente (C) o un proveedor (P).
En el campo Titular guardaremos el código de cliente o de proveedor.
Partiendo de la tabla Pagos, con los campos TipoTitular y Titular podemos
localizar el Titular en la tabla que le corresponda.

Oki, ahora ¿cómo representar esto en un formulario? Mediante combos
dependientes.

Crearemos un combo para elegir el TipoTitular. De este combo dependerá el
combo Titulares, que modificará su origen de datos cuando se modifique el
TipoTitular. Es decir, si yo elijo en el combo Titular el tipo "Cliente",
automáticamente se me modificará el origen de datos del combo Titular para
presentarme todos los clientes de mi tabla. Al implementarlo veréis que

hay

que hacer alguna cosita más para mantener la consistencia, como por

ejemplo

cuando un tipo y código ya esté elegido y el usuario cambie el tipo a
posteriori, nos quedaremos en un estado inconsistente. Ejemplo:

El usuario elige tipo Clientes
El usuario elige un Cliente
El usuario elige Proveedores ¡¡¡¡!!!!!

En la tabla Pagos quedará Tipo Proveedor con un código perteneciente a un
Cliente. Inconsistencia al canto, nuestra base de datos hecha unos zorros,
bronca del cliente, arreglito por el morro y sofocón. Precaución a tomar:

Al

cambiar en el combo Tipo, si el estado actual es diferente al anterior,
borrar el código de Titular. Y de estas, unas cuantas.

En este ejemplo la generalización solo atañe a dos tablas, pero podrían

ser

más. El siguiente problema que se presenta es a la hora de listar los

pagos,

en un informe, por ejemplo. Habrá que montar una consulta que muestre los
datos correctos sacándolos de las tablas correctas. Para ello hay que

jugar,

de nuevo, con los dos campos.

En la dire http://fca.unl.edu.ar/agromatica/ag...unteER.doc

hay

una explicación bastante clarita de generalización y especialización.

Espero que el rollo os sirva de ayuda :)
Eva Etxebeste
[MS MVP]

"julian-vlc-sp" <ijulianARROBAiespana.es> escribió en el mensaje
news:%
> Puedes explicarte un poco más?
>
> Esta claro que puedo hacer dos combos, uno par clientes y otro para
> proveedores, y seleccionar uno, y poner el id en titular, pero luego,

como

> se a que tabla pertenece?, seria necesario un campo mas para indicar de
que
> tabla he cogido el id?
>
> Yo pensaba en hacer una unica tabla que fuese titulares, en lugar de las
dos
> de clientes y proveedores, e implementar un campo donde le digo si es
> cliente o proveedor (por ejemplo)
>
> De esta forma, al tener un id en la tabla pagos, siempre se donde ir a
> buscarlo (a la tabla titulares)
>
> Este caso se me ha presentado varias veces, por ejmplo, varias tablas de
> personas, operarios, clientes, proveedores, etc. segun en que
aplicaciones,
> no es problema, cada tabla la uso para una cosa, por ejemplo para

nominas

> solo uso operarios, para cobros solo clientes, etc, pero en otras
ocasiones,
> quisiera poder poner id de una persona de cualquier tabla, por ejemplo
para
> las felicitaciones de navidad (aprovechando que cada vez estamos mas
cerca)
>
> (Ni te cuento como lo he resuelto, lo dejo para el merengue).
>
> SALUDOS MIL (guapetona)
> julian-valencia-españa
>
>

No jomío, ni magistral ni doctora (ya me gustaría, ya) solo una enamorada de
las bases de datos :) Y es que en el diseño de aplicaciones (como en casi
todo) la belleza está en el interior ;)
Eva Etxebeste
[MS MVP]

"Jesus" escribió en el mensaje
news:%23F$V%

Magistral Dra. Etxebeste


"Eva Etxebeste" <eetxebesteARROBAhotmail.com> escribió en el mensaje
news:
> Perdónenme Vds. por no haber contestado, es que este hilo lo estaba
> siguiendo en otro ordenatriz y (vayaustéasaberporqué) me mezcla los post

y

> se come algún que otro mensaje.
>
> Estas cosas se entienden con bastante facilidad si vamos al modelo

Entidad

> Relación y establecemos que las entidades Clientes y Proveedores son
> entidades de bajo nivel y la entidad Titular es una entidad de alto

nivel

> resultado de la generalización de ambas. Es lo que se llama una

realación

> IS-A (es un).
>
> Partiendo de esto, relacionamos la entidad Pagos con la entidad

Titulares.

> Un titular puede ser un Cliente o un Proveedor. Amo a vé si yo puedo
dibujar
> esto con palitos y bolitas :)
>
> Pagos -- (Otras entidades)
> |
> Titular
> |
> IS-A
> /\
> / \
> Cliente Proveedor
>
> ¿Cómo representar esto en nuestro modelo de tablas? Evidentemente no

vamos

a
> crear una nueva tabla Titulares, añadiremos un nuevo campo en la tabla
pagos
> que, junto con el campo Titular, nos permitirá localizar sin problemas

el

> titular. Ejemplo que se entiende mejor:
>
> Pagos:
> IdPago
> Blablabla
> TipoTitular
> Titular
>
> El campo TipoTitular nos dirá si es un cliente (C) o un proveedor (P).
> En el campo Titular guardaremos el código de cliente o de proveedor.
> Partiendo de la tabla Pagos, con los campos TipoTitular y Titular

podemos

> localizar el Titular en la tabla que le corresponda.
>
> Oki, ahora ¿cómo representar esto en un formulario? Mediante combos
> dependientes.
>
> Crearemos un combo para elegir el TipoTitular. De este combo dependerá

el

> combo Titulares, que modificará su origen de datos cuando se modifique

el

> TipoTitular. Es decir, si yo elijo en el combo Titular el tipo

"Cliente",

> automáticamente se me modificará el origen de datos del combo Titular

para

> presentarme todos los clientes de mi tabla. Al implementarlo veréis que
hay
> que hacer alguna cosita más para mantener la consistencia, como por
ejemplo
> cuando un tipo y código ya esté elegido y el usuario cambie el tipo a
> posteriori, nos quedaremos en un estado inconsistente. Ejemplo:
>
> El usuario elige tipo Clientes
> El usuario elige un Cliente
> El usuario elige Proveedores ¡¡¡¡!!!!!
>
> En la tabla Pagos quedará Tipo Proveedor con un código perteneciente a

un

> Cliente. Inconsistencia al canto, nuestra base de datos hecha unos

zorros,

> bronca del cliente, arreglito por el morro y sofocón. Precaución a

tomar:

Al
> cambiar en el combo Tipo, si el estado actual es diferente al anterior,
> borrar el código de Titular. Y de estas, unas cuantas.
>
> En este ejemplo la generalización solo atañe a dos tablas, pero podrían
ser
> más. El siguiente problema que se presenta es a la hora de listar los
pagos,
> en un informe, por ejemplo. Habrá que montar una consulta que muestre

los

> datos correctos sacándolos de las tablas correctas. Para ello hay que
jugar,
> de nuevo, con los dos campos.
>
> En la dire http://fca.unl.edu.ar/agromatica/ag...unteER.doc
hay
> una explicación bastante clarita de generalización y especialización.
>
> Espero que el rollo os sirva de ayuda :)
> Eva Etxebeste
> [MS MVP]
>
> "julian-vlc-sp" <ijulianARROBAiespana.es> escribió en el mensaje
> news:%
> > Puedes explicarte un poco más?
> >
> > Esta claro que puedo hacer dos combos, uno par clientes y otro para
> > proveedores, y seleccionar uno, y poner el id en titular, pero luego,
como
> > se a que tabla pertenece?, seria necesario un campo mas para indicar

de

> que
> > tabla he cogido el id?
> >
> > Yo pensaba en hacer una unica tabla que fuese titulares, en lugar de

las

> dos
> > de clientes y proveedores, e implementar un campo donde le digo si es
> > cliente o proveedor (por ejemplo)
> >
> > De esta forma, al tener un id en la tabla pagos, siempre se donde ir a
> > buscarlo (a la tabla titulares)
> >
> > Este caso se me ha presentado varias veces, por ejmplo, varias tablas

de

> > personas, operarios, clientes, proveedores, etc. segun en que
> aplicaciones,
> > no es problema, cada tabla la uso para una cosa, por ejemplo para
nominas
> > solo uso operarios, para cobros solo clientes, etc, pero en otras
> ocasiones,
> > quisiera poder poner id de una persona de cualquier tabla, por ejemplo
> para
> > las felicitaciones de navidad (aprovechando que cada vez estamos mas
> cerca)
> >
> > (Ni te cuento como lo he resuelto, lo dejo para el merengue).
> >
> > SALUDOS MIL (guapetona)
> > julian-valencia-españa
> >
> >
>
>

Eva, me auto-apunto uno (por lo menos) ¿recuerdas lo de me gusta vuelta/vuelta), poco hecha ;-)

Un saludo E. Feijoo

"Eva Etxebeste" <eetxebesteARROBAhotmail.com> escribió en el mensaje news:
| No jomío, ni magistral ni doctora (ya me gustaría, ya) solo una enamorada de
| las bases de datos :) Y es que en el diseño de aplicaciones (como en casi
| todo) la belleza está en el interior ;)
| --
| Eva Etxebeste
| [MS MVP]
|
| "Jesus" escribió en el mensaje
| news:%23F$V%
| > Magistral Dra. Etxebeste
| >
| >
| > "Eva Etxebeste" <eetxebesteARROBAhotmail.com> escribió en el mensaje
| > news:
| > > Perdónenme Vds. por no haber contestado, es que este hilo lo estaba
| > > siguiendo en otro ordenatriz y (vayaustéasaberporqué) me mezcla los post
| y
| > > se come algún que otro mensaje.
| > >
| > > Estas cosas se entienden con bastante facilidad si vamos al modelo
| Entidad
| > > Relación y establecemos que las entidades Clientes y Proveedores son
| > > entidades de bajo nivel y la entidad Titular es una entidad de alto
| nivel
| > > resultado de la generalización de ambas. Es lo que se llama una
| realación
| > > IS-A (es un).
| > >
| > > Partiendo de esto, relacionamos la entidad Pagos con la entidad
| Titulares.
| > > Un titular puede ser un Cliente o un Proveedor. Amo a vé si yo puedo
| > dibujar
| > > esto con palitos y bolitas :)
| > >
| > > Pagos -- (Otras entidades)
| > > |
| > > Titular
| > > |
| > > IS-A
| > > /\
| > > / \
| > > Cliente Proveedor
| > >
| > > ¿Cómo representar esto en nuestro modelo de tablas? Evidentemente no
| vamos
| > a
| > > crear una nueva tabla Titulares, añadiremos un nuevo campo en la tabla
| > pagos
| > > que, junto con el campo Titular, nos permitirá localizar sin problemas
| el
| > > titular. Ejemplo que se entiende mejor:
| > >
| > > Pagos:
| > > IdPago
| > > Blablabla
| > > TipoTitular
| > > Titular
| > >
| > > El campo TipoTitular nos dirá si es un cliente (C) o un proveedor (P).
| > > En el campo Titular guardaremos el código de cliente o de proveedor.
| > > Partiendo de la tabla Pagos, con los campos TipoTitular y Titular
| podemos
| > > localizar el Titular en la tabla que le corresponda.
| > >
| > > Oki, ahora ¿cómo representar esto en un formulario? Mediante combos
| > > dependientes.
| > >
| > > Crearemos un combo para elegir el TipoTitular. De este combo dependerá
| el
| > > combo Titulares, que modificará su origen de datos cuando se modifique
| el
| > > TipoTitular. Es decir, si yo elijo en el combo Titular el tipo
| "Cliente",
| > > automáticamente se me modificará el origen de datos del combo Titular
| para
| > > presentarme todos los clientes de mi tabla. Al implementarlo veréis que
| > hay
| > > que hacer alguna cosita más para mantener la consistencia, como por
| > ejemplo
| > > cuando un tipo y código ya esté elegido y el usuario cambie el tipo a
| > > posteriori, nos quedaremos en un estado inconsistente. Ejemplo:
| > >
| > > El usuario elige tipo Clientes
| > > El usuario elige un Cliente
| > > El usuario elige Proveedores ¡¡¡¡!!!!!
| > >
| > > En la tabla Pagos quedará Tipo Proveedor con un código perteneciente a
| un
| > > Cliente. Inconsistencia al canto, nuestra base de datos hecha unos
| zorros,
| > > bronca del cliente, arreglito por el morro y sofocón. Precaución a
| tomar:
| > Al
| > > cambiar en el combo Tipo, si el estado actual es diferente al anterior,
| > > borrar el código de Titular. Y de estas, unas cuantas.
| > >
| > > En este ejemplo la generalización solo atañe a dos tablas, pero podrían
| > ser
| > > más. El siguiente problema que se presenta es a la hora de listar los
| > pagos,
| > > en un informe, por ejemplo. Habrá que montar una consulta que muestre
| los
| > > datos correctos sacándolos de las tablas correctas. Para ello hay que
| > jugar,
| > > de nuevo, con los dos campos.
| > >
| > > En la dire http://fca.unl.edu.ar/agromatica/ag...unteER.doc
| > hay
| > > una explicación bastante clarita de generalización y especialización.
| > >
| > > Espero que el rollo os sirva de ayuda :)
| > > --
| > > Eva Etxebeste
| > > [MS MVP]
| > >
| > > "julian-vlc-sp" <ijulianARROBAiespana.es> escribió en el mensaje
| > > news:%
| > > > Puedes explicarte un poco más?
| > > >
| > > > Esta claro que puedo hacer dos combos, uno par clientes y otro para
| > > > proveedores, y seleccionar uno, y poner el id en titular, pero luego,
| > como
| > > > se a que tabla pertenece?, seria necesario un campo mas para indicar
| de
| > > que
| > > > tabla he cogido el id?
| > > >
| > > > Yo pensaba en hacer una unica tabla que fuese titulares, en lugar de
| las
| > > dos
| > > > de clientes y proveedores, e implementar un campo donde le digo si es
| > > > cliente o proveedor (por ejemplo)
| > > >
| > > > De esta forma, al tener un id en la tabla pagos, siempre se donde ir a
| > > > buscarlo (a la tabla titulares)
| > > >
| > > > Este caso se me ha presentado varias veces, por ejmplo, varias tablas
| de
| > > > personas, operarios, clientes, proveedores, etc. segun en que
| > > aplicaciones,
| > > > no es problema, cada tabla la uso para una cosa, por ejemplo para
| > nominas
| > > > solo uso operarios, para cobros solo clientes, etc, pero en otras
| > > ocasiones,
| > > > quisiera poder poner id de una persona de cualquier tabla, por ejemplo
| > > para
| > > > las felicitaciones de navidad (aprovechando que cada vez estamos mas
| > > cerca)
| > > >
| > > > (Ni te cuento como lo he resuelto, lo dejo para el merengue).
| > > >
| > > > SALUDOS MIL (guapetona)
| > > > julian-valencia-españa
| > > >
| > > >
| > >
| > >
| >
| >
|
|

Será %$&#@.. XDDDDDDDDDDDDDDDDDDDDDDDD

No te lo apuntes tan rápido, en el caso que nos ocupaba por aquél entonces,
lo que había en el interior era inteligencia (aunque discrepe con la dama en
más de un punto de vista) pero lo de la belleza aún está por demostrar
:)

Buena memoria caballero, el guante sigue volando :)
Eva Etxebeste
[MS MVP]

"E.Feijoo" <e.feijoo()retemail.es> escribió en el mensaje
news:%23W$
Eva, me auto-apunto uno (por lo menos) ¿recuerdas lo de me gusta
vuelta/vuelta), poco hecha ;-)

Un saludo E. Feijoo

"Eva Etxebeste" <eetxebesteARROBAhotmail.com> escribió en el mensaje
news:
| No jomío, ni magistral ni doctora (ya me gustaría, ya) solo una enamorada
de
| las bases de datos :) Y es que en el diseño de aplicaciones (como en casi
| todo) la belleza está en el interior ;)
| --
| Eva Etxebeste
| [MS MVP]
|
| "Jesus" escribió en el mensaje
| news:%23F$V%
| > Magistral Dra. Etxebeste
| >
| >
| > "Eva Etxebeste" <eetxebesteARROBAhotmail.com> escribió en el mensaje
| > news:
| > > Perdónenme Vds. por no haber contestado, es que este hilo lo estaba
| > > siguiendo en otro ordenatriz y (vayaustéasaberporqué) me mezcla los
post
| y
| > > se come algún que otro mensaje.
| > >
| > > Estas cosas se entienden con bastante facilidad si vamos al modelo
| Entidad
| > > Relación y establecemos que las entidades Clientes y Proveedores son
| > > entidades de bajo nivel y la entidad Titular es una entidad de alto
| nivel
| > > resultado de la generalización de ambas. Es lo que se llama una
| realación
| > > IS-A (es un).
| > >
| > > Partiendo de esto, relacionamos la entidad Pagos con la entidad
| Titulares.
| > > Un titular puede ser un Cliente o un Proveedor. Amo a vé si yo puedo
| > dibujar
| > > esto con palitos y bolitas :)
| > >
| > > Pagos -- (Otras entidades)
| > > |
| > > Titular
| > > |
| > > IS-A
| > > /\
| > > / \
| > > Cliente Proveedor
| > >
| > > ¿Cómo representar esto en nuestro modelo de tablas? Evidentemente no
| vamos
| > a
| > > crear una nueva tabla Titulares, añadiremos un nuevo campo en la tabla
| > pagos
| > > que, junto con el campo Titular, nos permitirá localizar sin problemas
| el
| > > titular. Ejemplo que se entiende mejor:
| > >
| > > Pagos:
| > > IdPago
| > > Blablabla
| > > TipoTitular
| > > Titular
| > >
| > > El campo TipoTitular nos dirá si es un cliente (C) o un proveedor (P).
| > > En el campo Titular guardaremos el código de cliente o de proveedor.
| > > Partiendo de la tabla Pagos, con los campos TipoTitular y Titular
| podemos
| > > localizar el Titular en la tabla que le corresponda.
| > >
| > > Oki, ahora ¿cómo representar esto en un formulario? Mediante combos
| > > dependientes.
| > >
| > > Crearemos un combo para elegir el TipoTitular. De este combo dependerá
| el
| > > combo Titulares, que modificará su origen de datos cuando se modifique
| el
| > > TipoTitular. Es decir, si yo elijo en el combo Titular el tipo
| "Cliente",
| > > automáticamente se me modificará el origen de datos del combo Titular
| para
| > > presentarme todos los clientes de mi tabla. Al implementarlo veréis
que
| > hay
| > > que hacer alguna cosita más para mantener la consistencia, como por
| > ejemplo
| > > cuando un tipo y código ya esté elegido y el usuario cambie el tipo a
| > > posteriori, nos quedaremos en un estado inconsistente. Ejemplo:
| > >
| > > El usuario elige tipo Clientes
| > > El usuario elige un Cliente
| > > El usuario elige Proveedores ¡¡¡¡!!!!!
| > >
| > > En la tabla Pagos quedará Tipo Proveedor con un código perteneciente a
| un
| > > Cliente. Inconsistencia al canto, nuestra base de datos hecha unos
| zorros,
| > > bronca del cliente, arreglito por el morro y sofocón. Precaución a
| tomar:
| > Al
| > > cambiar en el combo Tipo, si el estado actual es diferente al
anterior,
| > > borrar el código de Titular. Y de estas, unas cuantas.
| > >
| > > En este ejemplo la generalización solo atañe a dos tablas, pero
podrían
| > ser
| > > más. El siguiente problema que se presenta es a la hora de listar los
| > pagos,
| > > en un informe, por ejemplo. Habrá que montar una consulta que muestre
| los
| > > datos correctos sacándolos de las tablas correctas. Para ello hay que
| > jugar,
| > > de nuevo, con los dos campos.
| > >
| > > En la dire http://fca.unl.edu.ar/agromatica/ag...unteER.doc
| > hay
| > > una explicación bastante clarita de generalización y especialización.
| > >
| > > Espero que el rollo os sirva de ayuda :)
| > > --
| > > Eva Etxebeste
| > > [MS MVP]
| > >
| > > "julian-vlc-sp" <ijulianARROBAiespana.es> escribió en el mensaje
| > > news:%
| > > > Puedes explicarte un poco más?
| > > >
| > > > Esta claro que puedo hacer dos combos, uno par clientes y otro para
| > > > proveedores, y seleccionar uno, y poner el id en titular, pero
luego,
| > como
| > > > se a que tabla pertenece?, seria necesario un campo mas para indicar
| de
| > > que
| > > > tabla he cogido el id?
| > > >
| > > > Yo pensaba en hacer una unica tabla que fuese titulares, en lugar de
| las
| > > dos
| > > > de clientes y proveedores, e implementar un campo donde le digo si
es
| > > > cliente o proveedor (por ejemplo)
| > > >
| > > > De esta forma, al tener un id en la tabla pagos, siempre se donde ir
a
| > > > buscarlo (a la tabla titulares)
| > > >
| > > > Este caso se me ha presentado varias veces, por ejmplo, varias
tablas
| de
| > > > personas, operarios, clientes, proveedores, etc. segun en que
| > > aplicaciones,
| > > > no es problema, cada tabla la uso para una cosa, por ejemplo para
| > nominas
| > > > solo uso operarios, para cobros solo clientes, etc, pero en otras
| > > ocasiones,
| > > > quisiera poder poner id de una persona de cualquier tabla, por
ejemplo
| > > para
| > > > las felicitaciones de navidad (aprovechando que cada vez estamos mas
| > > cerca)
| > > >
| > > > (Ni te cuento como lo he resuelto, lo dejo para el merengue).
| > > >
| > > > SALUDOS MIL (guapetona)
| > > > julian-valencia-españa
| > > >
| > > >
| > >
| > >
| >
| >
|
|