Campo dependiente de otros campos en varias tablas

Me parece estupenda la especialización, pero como solucionamos la integridad
referencial, en el sentido que la maneja el motor JET (eliminación y
actulización en cascada). Quizás si dispusieramos de disparadores, estos
implementarían en la lógica de la base de datos esa integridad.

TablaClientes
TablaProveedores

TablaGastos
... Titular ...

Titular = Clientes + Proveedores

Modificamos la clave de un Cliente -> ¿no se entera el campo Titular?

Saludos!!!

ya tamos aquí de nuevo,

Aun a sí, ya puestos, hay una ciferencia. El propone un campo texto y yo

un Id, o sea, un indice.

¿¿Me quieres decir que un campo texto no puede ser un índice??, por que
desde luego un Id no es un tipo de datos.






Filosofía compartida: "regalamos conocimientos, no tiempo."...

y para no perderlo donde no queramos,
http://www.microsoft.com/spain/tech...9-USER.asp




Un Saludo,

Rafael Andrada C.
McPegasus
Valencia (es)

[MS MVP - Access]

www.mcpegasus.com

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

Disculpad, en la ultima nota ya indico que acababa de leer la respuesta

que

identificaba la idea con la mia, es decir, cuando respondí no la había
leido.
Aun a sí, ya puestos, hay una ciferencia. El propone un campo texto y yo

un

Id, o sea, un indice.
Ya no lio mas...:-(



"McPegasus" escribió en el mensaje
news:#
> Y me dicen a mí que soy un liante de cojones :(((
>
> Tú dices que Julián dice...
> > Julian:
> > "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?"
> > Es justo lo que yo propongo, que a mi entender es totalmente
normalizado,
> me
>
> Si lo dice Julián, digo yo, que será Julián el que lo propone, síquesí,
que
> tú también lo reiteras :)), de categoría ;)))
>
>
>
> Filosofía compartida: "regalamos conocimientos, no tiempo."...
>
> y para no perderlo donde no queramos,
>

http://www.microsoft.com/spain/tech...9-USER.asp

>
>
>
>
> Un Saludo,
>
> Rafael Andrada C.
> McPegasus
> Valencia (es)
>
> [MS MVP - Access]
>
> www.mcpegasus.com
>
> "Jesus" <jherrAlgarrobaWanadu.es> escribió en el mensaje
> news:eQpyN%
> > Eva, no sé si me llegan mal los hilos, pero ahora leo en un mensaje de
> > Julian:
> > "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?"
> > Es justo lo que yo propongo, que a mi entender es totalmente
normalizado,
> me
> > explico:
> > TClientes
> > TProveedores
> > TTipo (C ó P)
> > TPedidos
> >
> > En TPedidos un Id a TTipo.
> >
> > Tal vez no sea esta la cuestión planteada, en cuyo caso me disculpo.
> > En cualquier caso, me interesa mucho tu opinión al respecto.
> >
> >
> > "Eva Etxebeste" <eetxebesteARROBAhotmail.com> escribió en el mensaje
> > news:
> > > Jesús, o he entendido muy mal la tuya, o es exactamente la misma que
la
> > que
> > > propone Julián. Ambas igual de desnormalizadas, por tanto
> > > 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:
> > > > Descabellada no, desnormalizada, tal vez.
> > > > Me gusta mas la idea que te he señalado. Creo que es más segura.
> > > >
> > > >
> > > > "José Mª Fueyo (Desde el curro)" escribió

en

el
> > > > mensaje news:
> > > > > Mientras no se ponga a repartir collejas...:-S
> > > > >
> > > > > Salu2
> > > > > José Mª Fueyo
> > > > > [MS-MVP Access]
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Por supuesto, pero al indicar solo campo de texto, me pongo pesimista y
pienso que no lo va a indexar.
Aun así, prefiero indexar numéricos (esto puede ser una de mis paranoias).


"McPegasus" escribió en el mensaje
news:

ya tamos aquí de nuevo,

> Aun a sí, ya puestos, hay una ciferencia. El propone un campo texto y yo
un Id, o sea, un indice.

¿¿Me quieres decir que un campo texto no puede ser un índice??, por que
desde luego un Id no es un tipo de datos.






Filosofía compartida: "regalamos conocimientos, no tiempo."...

y para no perderlo donde no queramos,

http://www.microsoft.com/spain/tech...9-USER.asp

Un Saludo,

Rafael Andrada C.
McPegasus
Valencia (es)

[MS MVP - Access]

www.mcpegasus.com

"Jesus" <jherrAlgarrobaWanadu.es> escribió en el mensaje
news:
> Disculpad, en la ultima nota ya indico que acababa de leer la respuesta
que
> identificaba la idea con la mia, es decir, cuando respondí no la había
> leido.
> Aun a sí, ya puestos, hay una ciferencia. El propone un campo texto y yo
un
> Id, o sea, un indice.
> Ya no lio mas...:-(
>
>
>
> "McPegasus" escribió en el mensaje
> news:#
> > Y me dicen a mí que soy un liante de cojones :(((
> >
> > Tú dices que Julián dice...
> > > Julian:
> > > "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?"
> > > Es justo lo que yo propongo, que a mi entender es totalmente
> normalizado,
> > me
> >
> > Si lo dice Julián, digo yo, que será Julián el que lo propone,

síquesí,

> que
> > tú también lo reiteras :)), de categoría ;)))
> >
> >
> >
> > Filosofía compartida: "regalamos conocimientos, no tiempo."...
> >
> > y para no perderlo donde no queramos,
> >
>

http://www.microsoft.com/spain/tech...9-USER.asp

> >
> >
> >
> >
> > Un Saludo,
> >
> > Rafael Andrada C.
> > McPegasus
> > Valencia (es)
> >
> > [MS MVP - Access]
> >
> > www.mcpegasus.com
> >
> > "Jesus" <jherrAlgarrobaWanadu.es> escribió en el mensaje
> > news:eQpyN%
> > > Eva, no sé si me llegan mal los hilos, pero ahora leo en un mensaje

de

> > > Julian:
> > > "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?"
> > > Es justo lo que yo propongo, que a mi entender es totalmente
> normalizado,
> > me
> > > explico:
> > > TClientes
> > > TProveedores
> > > TTipo (C ó P)
> > > TPedidos
> > >
> > > En TPedidos un Id a TTipo.
> > >
> > > Tal vez no sea esta la cuestión planteada, en cuyo caso me disculpo.
> > > En cualquier caso, me interesa mucho tu opinión al respecto.
> > >
> > >
> > > "Eva Etxebeste" <eetxebesteARROBAhotmail.com> escribió en el mensaje
> > > news:
> > > > Jesús, o he entendido muy mal la tuya, o es exactamente la misma

que

> la
> > > que
> > > > propone Julián. Ambas igual de desnormalizadas, por tanto
> > > > 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:
> > > > > Descabellada no, desnormalizada, tal vez.
> > > > > Me gusta mas la idea que te he señalado. Creo que es más segura.
> > > > >
> > > > >
> > > > > "José Mª Fueyo (Desde el curro)" escribió
en
> el
> > > > > mensaje news:
> > > > > > Mientras no se ponga a repartir collejas...:-S
> > > > > >
> > > > > > Salu2
> > > > > > José Mª Fueyo
> > > > > > [MS-MVP Access]
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Que lío os estáis montando, y ya puestos, (y considerando un ID como un campo inequívoco que referencia al registro) ninguno es valido, dado que ambos (el 1 y la C o el 2 y la P) se reiterarían.

Habría que usar como ID la unión de ambos, y para ello liar mas el código y no habría forma de crear reglas consecuentes (o utilizar las propias del Access) y habría que tener en cuenta el/los casos en que un mismo 'objeto' pudiera ser cliente y proveedor

Soy partidario de separar los clientes y los proveedores en tablas diferentes, además, aunque tengan campos comunes, también pueden tener campos que los diferencien (e importantes en función del uso que se desee hacer de los datos)

Si realmente deseaseis evitar la 'casual' repetición de datos (el binomio cliente/proveedor), no lo evitaríais pues habría que duplicar 'el registro', uno con (1/p) y otro con (2/c), así puestos:
¿cual es la ventaja de una única tabla?
y
¿cuales son las pegas de tener dos tablas?.

Lo importante es que los datos sean manejables con el 'mínimo' esfuerzo y los mejores resultados, es mas rápida una localización en un conjunto de 100 o 20 registros con un único índice que en una de 120 registros con dos índices (o índice compuesto de dos campos)

Un saludo E. Feijoo


"McPegasus" escribió en el mensaje news:
| ya tamos aquí de nuevo,
|
| > Aun a sí, ya puestos, hay una ciferencia. El propone un campo texto y yo
| un Id, o sea, un indice.
|
| ¿¿Me quieres decir que un campo texto no puede ser un índice??, por que
| desde luego un Id no es un tipo de datos.
|
|
|
| --
|
|
|
| Filosofía compartida: "regalamos conocimientos, no tiempo."...
|
| y para no perderlo donde no queramos,
| http://www.microsoft.com/spain/tech...9-USER.asp
|
|
|
|
| Un Saludo,
|
| Rafael Andrada C.
| McPegasus
| Valencia (es)
|
| [MS MVP - Access]
|
| www.mcpegasus.com
|
| "Jesus" <jherrAlgarrobaWanadu.es> escribió en el mensaje
| news:
| > Disculpad, en la ultima nota ya indico que acababa de leer la respuesta
| que
| > identificaba la idea con la mia, es decir, cuando respondí no la había
| > leido.
| > Aun a sí, ya puestos, hay una ciferencia. El propone un campo texto y yo
| un
| > Id, o sea, un indice.
| > Ya no lio mas...:-(
| >
| >
| >
| > "McPegasus" escribió en el mensaje
| > news:#
| > > Y me dicen a mí que soy un liante de cojones :(((
| > >
| > > Tú dices que Julián dice...
| > > > Julian:
| > > > "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?"
| > > > Es justo lo que yo propongo, que a mi entender es totalmente
| > normalizado,
| > > me
| > >
| > > Si lo dice Julián, digo yo, que será Julián el que lo propone, síquesí,
| > que
| > > tú también lo reiteras :)), de categoría ;)))
| > > --
| > >
| > >
| > >
| > > Filosofía compartida: "regalamos conocimientos, no tiempo."...
| > >
| > > y para no perderlo donde no queramos,
| > >
| >
| http://www.microsoft.com/spain/tech...9-USER.asp
| > >
| > >
| > >
| > >
| > > Un Saludo,
| > >
| > > Rafael Andrada C.
| > > McPegasus
| > > Valencia (es)
| > >
| > > [MS MVP - Access]
| > >
| > > www.mcpegasus.com
| > >
| > > "Jesus" <jherrAlgarrobaWanadu.es> escribió en el mensaje
| > > news:eQpyN%
| > > > Eva, no sé si me llegan mal los hilos, pero ahora leo en un mensaje de
| > > > Julian:
| > > > "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?"
| > > > Es justo lo que yo propongo, que a mi entender es totalmente
| > normalizado,
| > > me
| > > > explico:
| > > > TClientes
| > > > TProveedores
| > > > TTipo (C ó P)
| > > > TPedidos
| > > >
| > > > En TPedidos un Id a TTipo.
| > > >
| > > > Tal vez no sea esta la cuestión planteada, en cuyo caso me disculpo.
| > > > En cualquier caso, me interesa mucho tu opinión al respecto.
| > > >
| > > >
| > > > "Eva Etxebeste" <eetxebesteARROBAhotmail.com> escribió en el mensaje
| > > > news:
| > > > > Jesús, o he entendido muy mal la tuya, o es exactamente la misma que
| > la
| > > > que
| > > > > propone Julián. Ambas igual de desnormalizadas, por tanto
| > > > > --
| > > > > 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:
| > > > > > Descabellada no, desnormalizada, tal vez.
| > > > > > Me gusta mas la idea que te he señalado. Creo que es más segura.
| > > > > >
| > > > > >
| > > > > > "José Mª Fueyo (Desde el curro)" escribió
| en
| > el
| > > > > > mensaje news:
| > > > > > > Mientras no se ponga a repartir collejas...:-S
| > > > > > >
| > > > > > > Salu2
| > > > > > > --
| > > > > > > José Mª Fueyo
| > > > > > > [MS-MVP Access]
| > > > > > >
| > > > > > >
| > > > > >
| > > > > >
| > > > >
| > > > >
| > > >
| > > >
| > >
| > >
| >
| >
|
|

Mira tú que estamos completamente de acuerdo :) El problema está en la
integridad referencial implementada con Access
Eva Etxebeste
[MS MVP]
***IMPORTANTE*** Microsoft Security Bulletin MS03-039
http://www.microsoft.com/security/s...03-039.asp

"E.Feijoo" <e.feijoo()retemail.es> escribió en el mensaje
news:#70OXL#
Que lío os estáis montando, y ya puestos, (y considerando un ID como un
campo inequívoco que referencia al registro) ninguno es valido, dado que
ambos (el 1 y la C o el 2 y la P) se reiterarían.

Habría que usar como ID la unión de ambos, y para ello liar mas el código y
no habría forma de crear reglas consecuentes (o utilizar las propias del
Access) y habría que tener en cuenta el/los casos en que un mismo 'objeto'
pudiera ser cliente y proveedor

Soy partidario de separar los clientes y los proveedores en tablas
diferentes, además, aunque tengan campos comunes, también pueden tener
campos que los diferencien (e importantes en función del uso que se desee
hacer de los datos)

Si realmente deseaseis evitar la 'casual' repetición de datos (el binomio
cliente/proveedor), no lo evitaríais pues habría que duplicar 'el registro',
uno con (1/p) y otro con (2/c), así puestos:
¿cual es la ventaja de una única tabla?
y
¿cuales son las pegas de tener dos tablas?.

Lo importante es que los datos sean manejables con el 'mínimo' esfuerzo y
los mejores resultados, es mas rápida una localización en un conjunto de 100
o 20 registros con un único índice que en una de 120 registros con dos
índices (o índice compuesto de dos campos)

Un saludo E. Feijoo


"McPegasus" escribió en el mensaje
news:
| ya tamos aquí de nuevo,
|
| > Aun a sí, ya puestos, hay una ciferencia. El propone un campo texto y yo
| un Id, o sea, un indice.
|
| ¿¿Me quieres decir que un campo texto no puede ser un índice??, por que
| desde luego un Id no es un tipo de datos.
|
|
|
| --
|
|
|
| Filosofía compartida: "regalamos conocimientos, no tiempo."...
|
| y para no perderlo donde no queramos,
|
http://www.microsoft.com/spain/tech...9-USER.asp
|
|
|
|
| Un Saludo,
|
| Rafael Andrada C.
| McPegasus
| Valencia (es)
|
| [MS MVP - Access]
|
| www.mcpegasus.com
|
| "Jesus" <jherrAlgarrobaWanadu.es> escribió en el mensaje
| news:
| > Disculpad, en la ultima nota ya indico que acababa de leer la respuesta
| que
| > identificaba la idea con la mia, es decir, cuando respondí no la había
| > leido.
| > Aun a sí, ya puestos, hay una ciferencia. El propone un campo texto y yo
| un
| > Id, o sea, un indice.
| > Ya no lio mas...:-(
| >
| >
| >
| > "McPegasus" escribió en el mensaje
| > news:#
| > > Y me dicen a mí que soy un liante de cojones :(((
| > >
| > > Tú dices que Julián dice...
| > > > Julian:
| > > > "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?"
| > > > Es justo lo que yo propongo, que a mi entender es totalmente
| > normalizado,
| > > me
| > >
| > > Si lo dice Julián, digo yo, que será Julián el que lo propone,
síquesí,
| > que
| > > tú también lo reiteras :)), de categoría ;)))
| > > --
| > >
| > >
| > >
| > > Filosofía compartida: "regalamos conocimientos, no tiempo."...
| > >
| > > y para no perderlo donde no queramos,
| > >
| >
|
http://www.microsoft.com/spain/tech...9-USER.asp
| > >
| > >
| > >
| > >
| > > Un Saludo,
| > >
| > > Rafael Andrada C.
| > > McPegasus
| > > Valencia (es)
| > >
| > > [MS MVP - Access]
| > >
| > > www.mcpegasus.com
| > >
| > > "Jesus" <jherrAlgarrobaWanadu.es> escribió en el mensaje
| > > news:eQpyN%
| > > > Eva, no sé si me llegan mal los hilos, pero ahora leo en un mensaje
de
| > > > Julian:
| > > > "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?"
| > > > Es justo lo que yo propongo, que a mi entender es totalmente
| > normalizado,
| > > me
| > > > explico:
| > > > TClientes
| > > > TProveedores
| > > > TTipo (C ó P)
| > > > TPedidos
| > > >
| > > > En TPedidos un Id a TTipo.
| > > >
| > > > Tal vez no sea esta la cuestión planteada, en cuyo caso me disculpo.
| > > > En cualquier caso, me interesa mucho tu opinión al respecto.
| > > >
| > > >
| > > > "Eva Etxebeste" <eetxebesteARROBAhotmail.com> escribió en el mensaje
| > > > news:
| > > > > Jesús, o he entendido muy mal la tuya, o es exactamente la misma
que
| > la
| > > > que
| > > > > propone Julián. Ambas igual de desnormalizadas, por tanto
| > > > > --
| > > > > 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:
| > > > > > Descabellada no, desnormalizada, tal vez.
| > > > > > Me gusta mas la idea que te he señalado. Creo que es más segura.
| > > > > >
| > > > > >
| > > > > > "José Mª Fueyo (Desde el curro)" escribió
| en
| > el
| > > > > > mensaje news:
| > > > > > > Mientras no se ponga a repartir collejas...:-S
| > > > > > >
| > > > > > > Salu2
| > > > > > > --
| > > > > > > José Mª Fueyo
| > > > > > > [MS-MVP Access]
| > > > > > >
| > > > > > >
| > > > > >
| > > > > >
| > > > >
| > > > >
| > > >
| > > >
| > >
| > >
| >
| >
|
|