Campo dependiente de otros campos en varias tablas

Espero que te haya ido bien con la plancha

Y ahora a lo que vamos,

De esta forma, creo que no se puede usar la integridad referencial, que tan
bien nos va a los que no usamos codigo, estoy en lo cierto?

En este caso, y dado que clientes y proveedores son tablas candidatas a
tener los mismos campos, no podríamos hacer una solo tabla y ponerlos todos
juntos?

En el caso de que queramos diferenciarlos, para no hacerle un pedido a un
cliente por ejemplo, no bastaria con implementar un campo en cual pusiesemos
C ó P segun sea proveedor o cliente?

Agredeceria que a nivel teorico, y solo de diseño de tablas, me dieses tu
opinion sobre

La opcion que tu plantesas versus la que planteo yo.

SALUDOS y GRACIAS anticipadas
julian-valencia-españa (alias julito)

"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
>
>

Vamos a ver, diferenciemos claramente entre:

* integridad referencial
* la integridad referencial automática que tan amablemente nos proporciona
Access

En cuanto a la primera, ningún problema
En cuanto a la segunda, nos ha pillao el toro :(

No uso MDBs y la integridad referencial no la implemento de esta forma, no
te sé decir cómo solucionar el asunto. Vamos a ver qué cuentan otros foreros

Un saludo
Eva Etxebeste
[MS MVP]
***IMPORTANTE*** Microsoft Security Bulletin MS03-039
http://www.microsoft.com/security/s...03-039.asp

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

Espero que te haya ido bien con la plancha

Y ahora a lo que vamos,

De esta forma, creo que no se puede usar la integridad referencial, que

tan

bien nos va a los que no usamos codigo, estoy en lo cierto?

En este caso, y dado que clientes y proveedores son tablas candidatas a
tener los mismos campos, no podríamos hacer una solo tabla y ponerlos

todos

juntos?

En el caso de que queramos diferenciarlos, para no hacerle un pedido a un
cliente por ejemplo, no bastaria con implementar un campo en cual

pusiesemos

C ó P segun sea proveedor o cliente?

Agredeceria que a nivel teorico, y solo de diseño de tablas, me dieses tu
opinion sobre

La opcion que tu plantesas versus la que planteo yo.

SALUDOS y GRACIAS anticipadas
julian-valencia-españa (alias julito)

"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 sé si sigo bien el hilo. Ayer tuve un dia 'genial' y estoy espeso.
En casos similares yo suelo hacer una tabla maestra con un Id y un Texto : 1
Cliente 2 Proveedor
En la tabla que corresponda, pongo un Id vinculado a la que acabo de crear.
Con esto creo que se soluciona el problema.
Derrapo????????


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

Vamos a ver, diferenciemos claramente entre:

* integridad referencial
* la integridad referencial automática que tan amablemente nos proporciona
Access

En cuanto a la primera, ningún problema
En cuanto a la segunda, nos ha pillao el toro :(

No uso MDBs y la integridad referencial no la implemento de esta forma, no
te sé decir cómo solucionar el asunto. Vamos a ver qué cuentan otros

foreros

Un saludo
Eva Etxebeste
[MS MVP]
***IMPORTANTE*** Microsoft Security Bulletin MS03-039
http://www.microsoft.com/security/s...03-039.asp

"julian-vlc-sp" <ijulianARROBAiespana.es> escribió en el mensaje
news:
> Espero que te haya ido bien con la plancha
>
> Y ahora a lo que vamos,
>
> De esta forma, creo que no se puede usar la integridad referencial, que
tan
> bien nos va a los que no usamos codigo, estoy en lo cierto?
>
> En este caso, y dado que clientes y proveedores son tablas candidatas a
> tener los mismos campos, no podríamos hacer una solo tabla y ponerlos
todos
> juntos?
>
> En el caso de que queramos diferenciarlos, para no hacerle un pedido a

un

> cliente por ejemplo, no bastaria con implementar un campo en cual
pusiesemos
> C ó P segun sea proveedor o cliente?
>
> Agredeceria que a nivel teorico, y solo de diseño de tablas, me dieses

tu

> opinion sobre
>
> La opcion que tu plantesas versus la que planteo yo.
>
> SALUDOS y GRACIAS anticipadas
> julian-valencia-españa (alias julito)
>
> "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
> > >
> > >
> >
> >
>
>

Y en qué forma normal quieres que esté tu base de datos?
Eva Etxebeste
[MS MVP]
***IMPORTANTE*** Microsoft Security Bulletin MS03-039
http://www.microsoft.com/security/s...03-039.asp

"Jesus" <jherrAlgarrobaWanadu.es> escribió en el mensaje
news:

No sé si sigo bien el hilo. Ayer tuve un dia 'genial' y estoy espeso.
En casos similares yo suelo hacer una tabla maestra con un Id y un Texto :

1

Cliente 2 Proveedor
En la tabla que corresponda, pongo un Id vinculado a la que acabo de

crear.

Con esto creo que se soluciona el problema.
Derrapo????????


"Eva Etxebeste" <eetxebesteARROBAhotmail.com> escribió en el mensaje
news:
> Vamos a ver, diferenciemos claramente entre:
>
> * integridad referencial
> * la integridad referencial automática que tan amablemente nos

proporciona

> Access
>
> En cuanto a la primera, ningún problema
> En cuanto a la segunda, nos ha pillao el toro :(
>
> No uso MDBs y la integridad referencial no la implemento de esta forma,

no

> te sé decir cómo solucionar el asunto. Vamos a ver qué cuentan otros
foreros
>
> Un saludo
> Eva Etxebeste
> [MS MVP]
> ***IMPORTANTE*** Microsoft Security Bulletin MS03-039
> http://www.microsoft.com/security/s...03-039.asp
>
> "julian-vlc-sp" <ijulianARROBAiespana.es> escribió en el mensaje
> news:
> > Espero que te haya ido bien con la plancha
> >
> > Y ahora a lo que vamos,
> >
> > De esta forma, creo que no se puede usar la integridad referencial,

que

> tan
> > bien nos va a los que no usamos codigo, estoy en lo cierto?
> >
> > En este caso, y dado que clientes y proveedores son tablas candidatas

a

> > tener los mismos campos, no podríamos hacer una solo tabla y ponerlos
> todos
> > juntos?
> >
> > En el caso de que queramos diferenciarlos, para no hacerle un pedido a
un
> > cliente por ejemplo, no bastaria con implementar un campo en cual
> pusiesemos
> > C ó P segun sea proveedor o cliente?
> >
> > Agredeceria que a nivel teorico, y solo de diseño de tablas, me dieses
tu
> > opinion sobre
> >
> > La opcion que tu plantesas versus la que planteo yo.
> >
> > SALUDOS y GRACIAS anticipadas
> > julian-valencia-españa (alias julito)
> >
> > "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
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Si entiendo bien tu planteamiento, es una de las opciones que yo planteo, es
decir, clientes y proveedores en una unica tabla, y con un campo que sirve
par indicar si es cliente o proveedor.

¿He entendido bien?

SALUDOS MIL
julian-valencia-españa