Re: Actualizacion en Cascada de llave primaria

Buenas tardes compañeros.

Necesito que por favor me den luces, de como resolver de la mejor manera la siguiente situación: Debo actualizar un registro, más exactamente el documento de una persona, el cual es la llave primaria de una tabla de inscritos. Esa tabla, tiene registros relacionados en tablas hija.

Gracias por sus sportes

William Enrique Parra Alba
Ingeniero De Sistemas
Universidad Pedagógica y Tecnológica de Colombia
/\ /\
/ //\\ \
\ \\// /
/ / \ \
\/ \/

---------------------------------

Comparte video en la ventana de tus mensajes (y también tus fotos de Flickr).
Usa el nuevo Yahoo! Messenger versión Beta.
Visita http://e1.beta.messenger.yahoo.com/

On Fri, 9 Nov 2007 15:12:54 -0800 (PST), WILLIAM PARRA wrote
> Buenas tardes compañeros.

Hola William...

> Necesito que por favor me den luces, de como resolver de la mejor
> manera la siguiente situación: Debo actualizar un registro, más
> exactamente el documento de una persona, el cual es la llave
> primaria de una tabla de inscritos. Esa tabla, tiene registros
> relacionados en tablas hija.

Es una mala idea de diseño que un documento sea una llave primaria. Pueden
haber muchos tipos de documentos, algunos incluir letras inclusive, por lo
tanto, creo que lo mejor sería alterar la tabla agregándole un campo serial,
que sea éste la clave primaria y el documento quizás una clave "candidata"
(así se les llama no?).

De todas formas, sin necesidad de hacer ésto, si están definidas correctamente
las foreign keys (con el "on update cascade") deberías poder realizar el
cambio y que ese cambio se refleje en las tablas hijas, justamente ese es el
espíritu de definir las foreign keys.

> Gracias por sus sportes

Por nada estimado y buen fin de semana.

-
-------------------------------------------
Sebastián Villalba
sebastian(at)fcm(dot)unc(dot)edu(dot)ar
-------------------------------------------

El 9/11/07, WILLIAM PARRA <wilparra(at)yahoo(dot)com> escribió:
> Buenas tardes compañeros.
>
> Necesito que por favor me den luces, de como resolver de la mejor manera la
> siguiente situación: Debo actualizar un registro, más exactamente el
> documento de una persona, el cual es la llave primaria de una tabla de
> inscritos. Esa tabla, tiene registros relacionados en tablas hija.

No entendi...

>
> Gracias por sus sportes
>
>
> William Enrique Parra Alba
> Ingeniero De Sistemas
> Universidad Pedagógica y Tecnológica de Colombia
> /\ /\
> / //\\ \
> \ \\// /
> / / \ \
> \/ \/
>
> ________________________________
>
> Comparte video en la ventana de tus mensajes (y también tus fotos de
> Flickr).
> Usa el nuevo Yahoo! Messenger versión Beta.
> Visita http://e1.beta.messenger.yahoo.com/

--
_________________________________
Solo soy una mente genial en un cuerpo

usuario anonimo escribió:
> El 9/11/07, WILLIAM PARRA <wilparra(at)yahoo(dot)com> escribió:
>
>> Buenas tardes compañeros.
>>
>> Necesito que por favor me den luces, de como resolver de la mejor manera la
>> siguiente situación: Debo actualizar un registro, más exactamente el
>> documento de una persona, el cual es la llave primaria de una tabla de
>> inscritos. Esa tabla, tiene registros relacionados en tablas hija.
>>
>
> No entendi...
>
>
>
>> Gracias por sus sportes
>>
>>
>> William Enrique Parra Alba
>> Ingeniero De Sistemas
>> Universidad Pedagógica y Tecnológica de Colombia
>> /\ /\
>> / //\\ \
>> \ \\// /
>> / / \ \
>> \/ \/
>>
>> ________________________________
>>
>> Comparte video en la ventana de tus mensajes (y también tus fotos de
>> Flickr).
>> Usa el nuevo Yahoo! Messenger versión Beta.
>> Visita http://e1.beta.messenger.yahoo.com/
>>
>
>
>
Mas alla del diseño tienes que borrar desde las hijas al padre asi
mantienes la integridad referencial ... no se si me explico bien!!
Slds.
J.

El 9/11/07, Sebastián Villalba <sebastian(at)fcm(dot)unc(dot)edu(dot)ar> escribió:
> On Fri, 9 Nov 2007 15:12:54 -0800 (PST), WILLIAM PARRA wrote
> > Buenas tardes compañeros.
>
> Hola William...
>
> > Necesito que por favor me den luces, de como resolver de la mejor
> > manera la siguiente situación: Debo actualizar un registro, más
> > exactamente el documento de una persona, el cual es la llave
> > primaria de una tabla de inscritos. Esa tabla, tiene registros
> > relacionados en tablas hija.
>
> Es una mala idea de diseño que un documento sea una llave primaria. Pueden

a que se refieren con un "documento" ? un archivo guardado en un campo
de un registro ?

> haber muchos tipos de documentos, algunos incluir letras inclusive, por lo
> tanto, creo que lo mejor sería alterar la tabla agregándole un campo serial,
> que sea éste la clave primaria y el documento quizás una clave "candidata"
> (así se les llama no?).
>
> De todas formas, sin necesidad de hacer ésto, si están definidas correctamente
> las foreign keys (con el "on update cascade") deberías poder realizar el
> cambio y que ese cambio se refleje en las tablas hijas, justamente ese es el
> espíritu de definir las foreign keys.
>
> > Gracias por sus sportes
>
> Por nada estimado y buen fin de semana.
>
> -
> -------------------------------------------
> Sebastián Villalba
> sebastian(at)fcm(dot)unc(dot)edu(dot)ar
> -------------------------------------------
>
> --
> TIP 4: No hagas 'kill -9' a postmaster
>

--
_________________________________
Solo soy una mente genial en un cuerpo

On Fri, 9 Nov 2007 21:25:32 -0300, usuario anonimo wrote
> El 9/11/07, Sebastián Villalba <sebastian(at)fcm(dot)unc(dot)edu(dot)ar> escribió:
> > On Fri, 9 Nov 2007 15:12:54 -0800 (PST), WILLIAM PARRA wrote
> > > Buenas tardes compañeros.
> >
> > Hola William...
> >
> > > Necesito que por favor me den luces, de como resolver de la mejor
> > > manera la siguiente situación: Debo actualizar un registro, más
> > > exactamente el documento de una persona, el cual es la llave
> > > primaria de una tabla de inscritos. Esa tabla, tiene registros
> > > relacionados en tablas hija.
> >
> > Es una mala idea de diseño que un documento sea una llave primaria. Pueden
>
> a que se refieren con un "documento" ? un archivo guardado en un
> campo de un registro ?

Oops!. Que buena pregunta.

Yo lo había interpretado a lo que aquí en Argentina llamamos "DNI" (Documento
Nacional de Identidad). A eso me refería cuando dije que pueden haber de
varios tipos (Cédulas de identidad, Pasaportes e inclusive se sabe que aquí en
Argentina hay números repetidos).

Por el contexto como lo escribió el amigo William, ni se me ocurrió pensar en
otro tipo de documentos (archivos electrónicos por ejemplo), pero honestamente
creo que se refiere a mi primer interpretación. William es la persona indicada
para salvar la duda. Saludos...

-
-------------------------------------------
Sebastián Villalba
sebastian(at)fcm(dot)unc(dot)edu(dot)ar
-------------------------------------------

--- Sebastián Villalba <sebastian(at)fcm(dot)unc(dot)edu(dot)ar>
escribió:

> On Fri, 9 Nov 2007 21:25:32 -0300, usuario anonimo
> wrote
> > El 9/11/07, Sebastián Villalba
> <sebastian(at)fcm(dot)unc(dot)edu(dot)ar> escribió:
> > > On Fri, 9 Nov 2007 15:12:54 -0800 (PST), WILLIAM
> PARRA wrote
> > > > Buenas tardes compañeros.
> > >
> > > Hola William...
> > >
> > > > Necesito que por favor me den luces, de como
> resolver de la mejor
> > > > manera la siguiente situación: Debo actualizar
> un registro, más
> > > > exactamente el documento de una persona, el
> cual es la llave
> > > > primaria de una tabla de inscritos. Esa tabla,
> tiene registros
> > > > relacionados en tablas hija.
> > >
> > > Es una mala idea de diseño que un documento sea
> una llave primaria. Pueden
> >
> > a que se refieren con un "documento" ? un archivo
> guardado en un
> > campo de un registro ?
>
> Oops!. Que buena pregunta.
>
> Yo lo había interpretado a lo que aquí en Argentina
> llamamos "DNI" (Documento
> Nacional de Identidad). A eso me refería cuando dije
> que pueden haber de
> varios tipos (Cédulas de identidad, Pasaportes e
> inclusive se sabe que aquí en
> Argentina hay números repetidos).
>
> Por el contexto como lo escribió el amigo William,
> ni se me ocurrió pensar en
> otro tipo de documentos (archivos electrónicos por
> ejemplo), pero honestamente
> creo que se refiere a mi primer interpretación.
> William es la persona indicada
> para salvar la duda. Saludos...
>
> -
> -------------------------------------------
> Sebastián Villalba
> sebastian(at)fcm(dot)unc(dot)edu(dot)ar
> -------------------------------------------
> --
> TIP 1: para suscribirte y desuscribirte, visita
> http://archives.postgresql.org/pgsql-es-ayuda
>
Tambien interprete lo mismo que tu, en Uruguay, no
sucede eso de que dos personas tengan su misma Cedula
de Identidad, el quivalente del DNI.

Claro somos poquitos habitantes y la mitad esta fuera
del pais, pero eso es harina de otro costal.

Pero entiendo igual que tu que se refiere a un
documento de identificacion, y si con las claves
tablas hijas tienen una relacion con claves foraneas
con actualizacion en cascada su caso esta resuelto,
ahi si es donde yo no entiendo que es lo que quiere
preguntar William Parra. Pero si es lo que me imagino
que lea sobre claves foraneas y listo.

Atte.
Gabriel Colina.

Comparte video en la ventana de tus mensajes (y también tus fotos de Flickr). Usa el nuevo Yahoo! Messenger versión Beta.
http://e1.beta.messenger.yahoo.com/

Sebastián Villalba escribió:
> On Fri, 9 Nov 2007 15:12:54 -0800 (PST), WILLIAM PARRA wrote
>> Buenas tardes compañeros.
>
> Hola William...
>
>> Necesito que por favor me den luces, de como resolver de la mejor
>> manera la siguiente situación: Debo actualizar un registro, más
>> exactamente el documento de una persona, el cual es la llave
>> primaria de una tabla de inscritos. Esa tabla, tiene registros
>> relacionados en tablas hija.
>
> Es una mala idea de diseño que un documento sea una llave primaria. Pueden
> haber muchos tipos de documentos, algunos incluir letras inclusive, por lo
> tanto, creo que lo mejor sería alterar la tabla agregándole un campo serial,
> que sea éste la clave primaria y el documento quizás una clave "candidata"
> (así se les llama no?).

Definí llave primaria y vas a ver que la llave primaria de una persona
en Argentina (de donde somos nosotros) es la 3-tupla
(tipo-doc,numero,sexo) (la ultima es justamente para evitar esa letra
que decis que a veces aparece).

Igualmente, yo a todas las tablas le pongo un campo SERIAL (con nombre
de campo unificado en todas las tablas) para usar de PK. Imaginate que
sino seria complicado atar una tabla a otra que tiene una PK formada por
3 columnas.

Simplemente, mis 2 centavos.

Martin Marques escribió:
> Sebastián Villalba escribió:
>> On Fri, 9 Nov 2007 15:12:54 -0800 (PST), WILLIAM PARRA wrote
>>> Buenas tardes compañeros.
>>
>> Hola William...
>>
>>> Necesito que por favor me den luces, de como resolver de la mejor
>>> manera la siguiente situación: Debo actualizar un registro, más
>>> exactamente el documento de una persona, el cual es la llave
>>> primaria de una tabla de inscritos. Esa tabla, tiene registros
>>> relacionados en tablas hija.
>>
>> Es una mala idea de diseño que un documento sea una llave primaria.
>> Pueden
>> haber muchos tipos de documentos, algunos incluir letras inclusive,
>> por lo
>> tanto, creo que lo mejor sería alterar la tabla agregándole un campo
>> serial,
>> que sea éste la clave primaria y el documento quizás una clave
>> "candidata"
>> (así se les llama no?).
>
> Definí llave primaria y vas a ver que la llave primaria de una persona
> en Argentina (de donde somos nosotros) es la 3-tupla
> (tipo-doc,numero,sexo) (la ultima es justamente para evitar esa letra
> que decis que a veces aparece).
>
> Igualmente, yo a todas las tablas le pongo un campo SERIAL (con nombre
> de campo unificado en todas las tablas) para usar de PK. Imaginate que
> sino seria complicado atar una tabla a otra que tiene una PK formada por
> 3 columnas.
>
> Simplemente, mis 2 centavos.
>
> --
> TIP 8: explain analyze es tu amigo
>
Pregunta aparte , dentro de esto mismo ... :o) entiendo que un campo
serial es un campo autoincrementable verdad???? diganme una cosa como se
comportan esos campos en PG porque yo por norma siempre prefiero
calcular el valor del campo cuando es una clave primaria porque me han
pasado tallas en sqlserver al menos que esos campos a veces se corrompen
y uffff me dio muuucho trabajo arreglar esas tablas especialmente cuando
tienen muuuchos registros.. lo otro siempre por ejemplo en un campo como
el DNI o RUT en chile dejo la clave con otro campo porque imaginense lo
que significaria si alguien se equivoca al ingresa uno de esos datos y
modificar una clave primaria... ufff... no se es solo para compartir
experiencias... que me pueden decir???
Slds.
Javier

Javier Chavez Barra escribió:
> Martin Marques escribió:
>> Sebastián Villalba escribió:
>>> On Fri, 9 Nov 2007 15:12:54 -0800 (PST), WILLIAM PARRA wrote
>>>> Buenas tardes compañeros.
>>>
>>> Hola William...
>>>
>>>> Necesito que por favor me den luces, de como resolver de la mejor
>>>> manera la siguiente situación: Debo actualizar un registro, más
>>>> exactamente el documento de una persona, el cual es la llave
>>>> primaria de una tabla de inscritos. Esa tabla, tiene registros
>>>> relacionados en tablas hija.
>>>
>>> Es una mala idea de diseño que un documento sea una llave primaria.
>>> Pueden
>>> haber muchos tipos de documentos, algunos incluir letras inclusive,
>>> por lo
>>> tanto, creo que lo mejor sería alterar la tabla agregándole un campo
>>> serial,
>>> que sea éste la clave primaria y el documento quizás una clave
>>> "candidata"
>>> (así se les llama no?).
>>
>> Definí llave primaria y vas a ver que la llave primaria de una persona
>> en Argentina (de donde somos nosotros) es la 3-tupla
>> (tipo-doc,numero,sexo) (la ultima es justamente para evitar esa letra
>> que decis que a veces aparece).
>>
>> Igualmente, yo a todas las tablas le pongo un campo SERIAL (con nombre
>> de campo unificado en todas las tablas) para usar de PK. Imaginate que
>> sino seria complicado atar una tabla a otra que tiene una PK formada por
>> 3 columnas.
>>
>> Simplemente, mis 2 centavos.
>>
>> --
>> TIP 8: explain analyze es tu amigo
>>
> Pregunta aparte , dentro de esto mismo ... :o) entiendo que un campo
> serial es un campo autoincrementable verdad????

Si, pero no es PK. Tenes que usar las palabras claves "PRIMARY KEY" para
que no haya nulos ni duplicados.

> diganme una cosa como se
> comportan esos campos en PG porque yo por norma siempre prefiero
> calcular el valor del campo cuando es una clave primaria porque me han
> pasado tallas en sqlserver al menos que esos campos a veces se corrompen

Nunca me paso. ¿Qué significa que se corrompe el campo? ¿En qué forma se
corrompe?

> y uffff me dio muuucho trabajo arreglar esas tablas especialmente cuando
> tienen muuuchos registros.. lo otro siempre por ejemplo en un campo como
> el DNI o RUT en chile dejo la clave con otro campo porque imaginense lo
> que significaria si alguien se equivoca al ingresa uno de esos datos y
> modificar una clave primaria... ufff... no se es solo para compartir
> experiencias... que me pueden decir???

Yo ya he escuchado muchas veces esto. Se puede actualizar perfectamente
si las referencias tienen el "ON CASCADE UPDATE".

Una tabla de personas para mi tendria campos algo asi: id (PK de tipo
BIGSERIAL), tipodoc (INT REFERENCIA a una tabla donde estan los tipos de
documentos validos), numero (INT8 (y no me alcanza asi siquiera) con el
numero de documento), nombres (VARCHAR(120) o mas... es por
experiencia), apellido (VARCHAR(120) idem anterior).

Despues cualquier tabla que tenga que tener como referencia a una
persona haria un REFERENCE persona(id). :-)

Martin Marques escribió:
> Javier Chavez Barra escribió:
>> Martin Marques escribió:
>>> Sebastián Villalba escribió:
>>>> On Fri, 9 Nov 2007 15:12:54 -0800 (PST), WILLIAM PARRA wrote
>>>>> Buenas tardes compañeros.
>>>>
>>>> Hola William...
>>>>
>>>>> Necesito que por favor me den luces, de como resolver de la mejor
>>>>> manera la siguiente situación: Debo actualizar un registro, más
>>>>> exactamente el documento de una persona, el cual es la llave
>>>>> primaria de una tabla de inscritos. Esa tabla, tiene registros
>>>>> relacionados en tablas hija.
>>>>
>>>> Es una mala idea de diseño que un documento sea una llave primaria.
>>>> Pueden
>>>> haber muchos tipos de documentos, algunos incluir letras inclusive,
>>>> por lo
>>>> tanto, creo que lo mejor sería alterar la tabla agregándole un
>>>> campo serial,
>>>> que sea éste la clave primaria y el documento quizás una clave
>>>> "candidata"
>>>> (así se les llama no?).
>>>
>>> Definí llave primaria y vas a ver que la llave primaria de una persona
>>> en Argentina (de donde somos nosotros) es la 3-tupla
>>> (tipo-doc,numero,sexo) (la ultima es justamente para evitar esa letra
>>> que decis que a veces aparece).
>>>
>>> Igualmente, yo a todas las tablas le pongo un campo SERIAL (con nombre
>>> de campo unificado en todas las tablas) para usar de PK. Imaginate que
>>> sino seria complicado atar una tabla a otra que tiene una PK formada
>>> por
>>> 3 columnas.
>>>
>>> Simplemente, mis 2 centavos.
>>>
>>> --
>>> TIP 8: explain analyze es tu amigo
>>>
>> Pregunta aparte , dentro de esto mismo ... :o) entiendo que un campo
>> serial es un campo autoincrementable verdad????
>
> Si, pero no es PK. Tenes que usar las palabras claves "PRIMARY KEY"
> para que no haya nulos ni duplicados.

>
>> diganme una cosa como se comportan esos campos en PG porque yo por
>> norma siempre prefiero calcular el valor del campo cuando es una
>> clave primaria porque me han pasado tallas en sqlserver al menos que
>> esos campos a veces se corrompen
>
> Nunca me paso. ¿Qué significa que se corrompe el campo? ¿En qué forma
> se corrompe?
Es una larga historia!! pero por un motivo que no tengo la mas remota
idea me calculo mal unas PK y al tratar de hacer un insert me reclamaba
clave duplicada!!!.. :S fue por eso ... pero bueno puede que PG no sea
asi ... era solo simple curiosidad

>
>> y uffff me dio muuucho trabajo arreglar esas tablas especialmente
>> cuando tienen muuuchos registros.. lo otro siempre por ejemplo en un
>> campo como el DNI o RUT en chile dejo la clave con otro campo porque
>> imaginense lo que significaria si alguien se equivoca al ingresa uno
>> de esos datos y modificar una clave primaria... ufff... no se es solo
>> para compartir experiencias... que me pueden decir???
>
> Yo ya he escuchado muchas veces esto. Se puede actualizar
> perfectamente si las referencias tienen el "ON CASCADE UPDATE".
>
> Una tabla de personas para mi tendria campos algo asi: id (PK de tipo
> BIGSERIAL), tipodoc (INT REFERENCIA a una tabla donde estan los tipos
> de documentos validos), numero (INT8 (y no me alcanza asi siquiera)
> con el numero de documento), nombres (VARCHAR(120) o mas... es por
> experiencia), apellido (VARCHAR(120) idem anterior).
>
> Despues cualquier tabla que tenga que tener como referencia a una
> persona haria un REFERENCE persona(id). :-)
>
Si pero = no se quiza soy un poco mas fundamentalista ... en ese sentido
prefiero tener el control como programador .. y no darle esa
responsabilidad al motor.. no se es simple asunto de crianza no.. no
subirme al auto automatico hasta no aprender bien a manejar el mecanico...
bueno pero es interesante... solo era curiosidad..
Slds.
Javier

WILLIAM PARRA escribió:
> Buenas tardes compañeros.
>
> Necesito que por favor me den luces, de como resolver de la mejor manera
> la siguiente situación: Debo actualizar un registro, más exactamente el
> documento de una persona, el cual es la llave primaria de una tabla de
> inscritos. Esa tabla, tiene registros relacionados en tablas hija.

En la tabla hija debes definir que la llave foranea la actualizacion sea
en cascada. Normalmente un ejemplo de esto seria:

ALTER TABLE hija DROP CONSTRAINT campo_fkey;
ALTER TABLE hija ADD CONSTRAINT campo_fkey FOREING KEY campo REFERENCES
tabla_padre(campo) ON UPDATE CASCADE;

Mira la doc sobre añadir este tipo de reglas en
http://www.postgresql.org/docs/8.2/static/sql-createtable.html

--
Juan Martinez G. Mac Iver # 370
Departamento de Informatica 4997900 - 4997934
Universidad Miguel de Cervantes Santiago - Chile
http://download.bblug.usla.org.ar/netiquette.png

[...]
> Pregunta aparte , dentro de esto mismo ... :o) entiendo que un campo
> serial es un campo autoincrementable verdad???? diganme una cosa como se
> comportan esos campos en PG porque yo por norma siempre prefiero
> calcular el valor del campo cuando es una clave primaria porque me han
> pasado tallas en sqlserver al menos que esos campos a veces se corrompen
> y uffff me dio muuucho trabajo arreglar esas tablas especialmente cuando
> tienen muuuchos registros.. lo otro siempre por ejemplo en un campo como
> el DNI o RUT en chile dejo la clave con otro campo porque imaginense lo
> que significaria si alguien se equivoca al ingresa uno de esos datos y
> modificar una clave primaria... ufff... no se es solo para compartir
> experiencias... que me pueden decir???
> Slds.
> Javier

Los campos serial se comportan como lo que dices, es un valor que se
auto incrementa y la probabilidad de que se asigne el mismo valor a
mas de un registro es casi nula si siempre a ese valor le asignas el
valor por default, por ejemplo ingresas registros asi:

insert into foo(clave_primaria_serial) values(default)
insert into foo(clave_primaria_serial) values(default)
insert into foo(clave_primaria_serial) values(1)

seguramente el ultimo insert chocara con el primer insert.

--
_________________________________
Solo soy una mente genial en un cuerpo

Muchisimas gracias.

Ese dato me soluciona el problema por completo. Respecto a la discución generada al respecto, es muy discutible dejarle la responsabilidad de la llave únicamente al motor. Ya que se presenta para que un registro pueda duplicarse n veces... y como la llave se genera automatica... Ahora, un caso de migración... buscar los registros hijos.... complicado...

Agradesco muchisimo los aportes, y voy a ver en que medida mejoro mi diseño.

Juan Martínez <jeugenio(at)umcervantes(dot)cl> escribió: WILLIAM PARRA escribió:
> Buenas tardes compañeros.
>
> Necesito que por favor me den luces, de como resolver de la mejor manera
> la siguiente situación: Debo actualizar un registro, más exactamente el
> documento de una persona, el cual es la llave primaria de una tabla de
> inscritos. Esa tabla, tiene registros relacionados en tablas hija.

En la tabla hija debes definir que la llave foranea la actualizacion sea
en cascada. Normalmente un ejemplo de esto seria:

ALTER TABLE hija DROP CONSTRAINT campo_fkey;
ALTER TABLE hija ADD CONSTRAINT campo_fkey FOREING KEY campo REFERENCES
tabla_padre(campo) ON UPDATE CASCADE;

Mira la doc sobre añadir este tipo de reglas en
http://www.postgresql.org/docs/8.2/static/sql-createtable.html

--
Juan Martinez G. Mac Iver # 370
Departamento de Informatica 4997900 - 4997934
Universidad Miguel de Cervantes Santiago - Chile
http://download.bblug.usla.org.ar/netiquette.png

William Enrique Parra Alba
Ingeniero De Sistemas
Universidad Pedagógica y Tecnológica de Colombia
/\ /\
/ //\\ \
\ \\// /
/ / \ \
\/ \/

---------------------------------

Comparte video en la ventana de tus mensajes (y también tus fotos de Flickr).
Usa el nuevo Yahoo! Messenger versión Beta.
Visita http://e1.beta.messenger.yahoo.com/

El 10/11/07, WILLIAM PARRA <wilparra(at)yahoo(dot)com> escribió:
> Muchisimas gracias.
>
> Ese dato me soluciona el problema por completo. Respecto a la discución
> generada al respecto, es muy discutible dejarle la responsabilidad de la
> llave únicamente al motor. Ya que se presenta para que un registro pueda
> duplicarse n veces... y como la llave se genera automatica... Ahora, un caso
> de migración... buscar los registros hijos.... complicado...

Eso no es asi, para cada valor unico como un RUT,RUN,DNI,PASAPORTE uno
puede definir que este sea unico. asi lo hago yo.

>
> Agradesco muchisimo los aportes, y voy a ver en que medida mejoro mi diseño.

--
_________________________________
Solo soy una mente genial en un cuerpo

usuario anonimo escribió:
> El 10/11/07, WILLIAM PARRA <wilparra(at)yahoo(dot)com> escribió:
>> Muchisimas gracias.
>>
>> Ese dato me soluciona el problema por completo. Respecto a la discución
>> generada al respecto, es muy discutible dejarle la responsabilidad de la
>> llave únicamente al motor. Ya que se presenta para que un registro pueda
>> duplicarse n veces... y como la llave se genera automatica... Ahora, un caso
>> de migración... buscar los registros hijos.... complicado...
>
> Eso no es asi, para cada valor unico como un RUT,RUN,DNI,PASAPORTE uno
> puede definir que este sea unico. asi lo hago yo.

Acoto a lo expresado: Uno define la PK, y luego no pueden haber datos
duplicados ni nulos, porque esa es la definicion de PK: NOT NULL y
UNIQUE (vean que en postgres se crea un inndice unico en cada PK que se
define)

WILLIAM PARRA escribió:
> Buenas tardes compañeros.
>
> Necesito que por favor me den luces, de como resolver de la mejor
> manera la siguiente situación: Debo actualizar un registro, más
> exactamente el documento de una persona, el cual es la llave primaria
> de una tabla de inscritos. Esa tabla, tiene registros relacionados en
> tablas hija.

Bueno, para eso existe el "ON UPDATE CASCADE".

Ahora, lo que dicen mas abajo en el thread es cierto: es pesima idea
(segun algunos; hay gente que no esta de acuerdo) usar un valor del
mundo real como llave primaria, porque estas sujeto a cambios como este.
Para tu salud mental es mejor crear una llave artificial y usarla como
llave primaria y para las referencias, de manera que cuando tengas que
cambiar el numero de documento de una persona por cualquier motivo, no
te veas obligado a hacer las actualizaciones de las tablas hijas.

Te lo recomiendo. Te ahorrara en aspirinas.

--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
"Always assume the user will do much worse than the stupidest thing
you can imagine." (Julien PUYDT)

> -----Mensaje original-----
> De: pgsql-es-ayuda-owner(at)postgresql(dot)org [mailto:pgsql-es-ayuda-
> owner(at)postgresql(dot)org] En nombre de Alvaro Herrera
> Enviado el: Lunes, 12 de Noviembre de 2007 9:24
> Para: WILLIAM PARRA
> CC: pgsql-es-ayuda(at)postgresql(dot)org
> Asunto: Re: [pgsql-es-ayuda] Actualizacion en Cascada de llave primaria
>
> WILLIAM PARRA escribió:
> > Buenas tardes compañeros.
> >
> > Necesito que por favor me den luces, de como resolver de la mejor
> > manera la siguiente situación: Debo actualizar un registro, más
> > exactamente el documento de una persona, el cual es la llave primaria
> > de una tabla de inscritos. Esa tabla, tiene registros relacionados en
> > tablas hija.
>
> Bueno, para eso existe el "ON UPDATE CASCADE".
>
> Ahora, lo que dicen mas abajo en el thread es cierto: es pesima idea
> (segun algunos; hay gente que no esta de acuerdo) usar un valor del
> mundo real como llave primaria, porque estas sujeto a cambios como
> este.
> Para tu salud mental es mejor crear una llave artificial y usarla como
> llave primaria y para las referencias, de manera que cuando tengas que
> cambiar el numero de documento de una persona por cualquier motivo, no
> te veas obligado a hacer las actualizaciones de las tablas hijas.
>
> Te lo recomiendo. Te ahorrara en aspirinas.
[Patricio Cifuentes Ithal]
Creo que en general el problema pasa por no implementar ingeniería social,
para hacer un poco tecnisista(papista).

Claro está bajo las normas de las reglas de las formas normales, que cada
registro único, 1,2 forma normal deben llevar un numero único e irrepetible
(valga de redundancia?), ese número puede ser un entero auto numérico, según
cada DBMS, o un entero controlado por el desarrollador (no es practico).

Ahora. Sabemos que para las personas existe un ID lógico en la vida real
generado por cada una de nuestras instituciones gubernamentales según el
país, DNI, RUT, CI pero esos pasan a hacer parte de un formulario de
ingenieria social, cuando el sistema le pregunta al cliente si quiere buscar
un usuario del mismo sistema, no le pedirá por el ID de la BD, si no q por
sus DNI, RUT, CI. O su nombre o apellido etc, esa es una interfaz amigable
de uso masivo y corresponde a la ingeniería social, luego de eso, el sistema
debe ser lo bastante inteligente o mas bien.. bien desarrollado q según ese
parámetro de búsqueda, encuentre el id único e irrepetible q lo identifica
relacionalmente, para después hacer las relaciones que correspondan a las
demás tablas.

También sugiero q lean los diferentes tipo de llaves que existen, no solo
existen las llaves primaria y foráneas.

>
> --
> Alvaro Herrera
> http://www.amazon.com/gp/registry/CTMLCN8V17R4
> "Always assume the user will do much worse than the stupidest thing
> you can imagine." (Julien PUYDT)
> --
> TIP 4: No hagas 'kill -9' a postmaster
>
> --
> Este mensaje ha sido analizado por MailScanner
> en busca de virus y otros contenidos peligrosos,
> y se considera que está limpio.
>
> www.siigsa.cl

--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.

www.siigsa.cl

> > >diganme una cosa como se comportan esos campos en PG porque yo
> > >por norma siempre prefiero calcular el valor del campo cuando es
> > >una clave primaria porque me han pasado tallas en sqlserver al
> > >menos que esos campos a veces se corrompen
> >
> > Nunca me paso. ¿Qué significa que se corrompe el campo? ¿En qué
> > forma se corrompe?
>
> Es una larga historia!! pero por un motivo que no tengo la mas
> remota idea me calculo mal unas PK y al tratar de hacer un insert me
> reclamaba clave duplicada!!!.. :S fue por eso ... pero bueno puede
> que PG no sea asi ... era solo simple curiosidad

Como dices, quién sabe que haya pasado - pero si llegaste a esa
situación (tal vez insertando IDs a mano sin haberle pedido a Postgres
que lo haga a través de la secuencia - Recuerda que la secuencia es un
mecanismo independiente de la tabla, que sólo sabe incrementarse cada
que lo llamas, y si no lo llamas pos nomás no se incrementa), pero es
muy fácil de solucionar (remítase a [1]): Para una tabla llamada
articulos, asumiendo que tu PK es id, y que tu secuencia es
articulos_id_seq,

SELECT setval(articulos_id_seq', (SELECT id FROM articulos ORDER BY id DESC LIMIT 1));

> >Yo ya he escuchado muchas veces esto. Se puede actualizar
> >perfectamente si las referencias tienen el "ON CASCADE UPDATE".
> >
> >Una tabla de personas para mi tendria campos algo asi: id (PK de
> >tipo BIGSERIAL), tipodoc (INT REFERENCIA a una tabla donde estan
> >los tipos de documentos validos), numero (INT8 (y no me alcanza asi
> >siquiera) con el numero de documento), nombres (VARCHAR(120) o
> >mas... es por experiencia), apellido (VARCHAR(120) idem anterior).
> >
> >Despues cualquier tabla que tenga que tener como referencia a una
> >persona haria un REFERENCE persona(id). :-)
>
> Si pero = no se quiza soy un poco mas fundamentalista ... en ese
> sentido prefiero tener el control como programador .. y no darle esa
> responsabilidad al motor.. no se es simple asunto de crianza no.. no
> subirme al auto automatico hasta no aprender bien a manejar el
> mecanico... bueno pero es interesante... solo era curiosidad..

Me suena a que aprendiste a usar BDs con algo tipo MySQL, ¿verdad? Es
mucho más confiable dejar que la BD lo haga. Si no, puedes caer
fácilmente en condiciones de carrera - Por ejemplo, si tu programa
incluye un SELECT id FROM articulos ORDER BY id DESC LIMIT 1 para
encontrar si el ID más alto empleado, el cual es incrementado en 1, y
después viene un INSERT INTO articulos (id, otros_campos) VALUES
(el_nuevo_id, los_otros_valores) - ¿Qué pasa si llegan dos solicitudes
a la vez? Recuerda que la comunicación con Postgres es via sockets,
pues es entre dos procesos de sistema diferentes, e implica un cambio
de contexto para el sistema operativo. Puedes terminar con una
excepción por PK duplicada - A menos que implmentes un sistema de
locking, semáforos o lo que gustes. ¡Ah! Olvidaba decírtelo: La buena
gente de Postgres se tomó la molestia de implementarlo por tí. Se
llama "secuencias" ;-)

Saludos,

[1] http://www.postgresql.org/docs/8.1/static/functions-sequence.html

--
Gunnar Wolf - gwolf(at)gwolf(dot)org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF

Gunnar Wolf escribió:
>>>> diganme una cosa como se comportan esos campos en PG porque yo
>>>> por norma siempre prefiero calcular el valor del campo cuando es
>>>> una clave primaria porque me han pasado tallas en sqlserver al
>>>> menos que esos campos a veces se corrompen
>>> Nunca me paso. ¿Qué significa que se corrompe el campo? ¿En qué
>>> forma se corrompe?
>> Es una larga historia!! pero por un motivo que no tengo la mas
>> remota idea me calculo mal unas PK y al tratar de hacer un insert me
>> reclamaba clave duplicada!!!.. :S fue por eso ... pero bueno puede
>> que PG no sea asi ... era solo simple curiosidad
>
> Como dices, quién sabe que haya pasado - pero si llegaste a esa
> situación (tal vez insertando IDs a mano sin haberle pedido a Postgres
> que lo haga a través de la secuencia - Recuerda que la secuencia es un
> mecanismo independiente de la tabla, que sólo sabe incrementarse cada
> que lo llamas, y si no lo llamas pos nomás no se incrementa), pero es
> muy fácil de solucionar (remítase a [1]): Para una tabla llamada
> articulos, asumiendo que tu PK es id, y que tu secuencia es
> articulos_id_seq,

Gunnar, él esta hablando de MSSQL. Yo la verdad es que desconozco como
trabaja ese motor.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Martin Marques wrote:
> Gunnar Wolf escribió:
>
> Gunnar, él esta hablando de MSSQL. Yo la verdad es que desconozco
> como trabaja ese motor.
Para crear claves unicas creo recordar que tenia un tipo de dato que
creaba un valor aleatorio de unos 16 bytes. El cual se supone que no
se repite en toda la bd nunca.
No recuerdo si tenia algo tipo serial.

Personalmente, trabaje con la 2k y fue suficiente para el resto de mi
vida. ^^U
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7-ecc0.1.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHOJpbFM7v59jybhQRCllIAKCg54eJql6//pCELc8LIXR/1V0ocQCgpTSP
h9zDch13zMUN3bmLfFe1p14=
=haR5
-----END PGP SIGNATURE-----

Hola

On Mon, 12 Nov 2007 11:29:30 -0600, Gunnar Wolf wrote
> > > >diganme una cosa como se comportan esos campos en PG porque yo
> > > >por norma siempre prefiero calcular el valor del campo cuando es
> > > >una clave primaria porque me han pasado tallas en sqlserver al
> > > >menos que esos campos a veces se corrompen
> > >
> > > Nunca me paso. ¿Qué significa que se corrompe el campo? ¿En qué
> > > forma se corrompe?
> >
> > Es una larga historia!! pero por un motivo que no tengo la mas
> > remota idea me calculo mal unas PK y al tratar de hacer un insert me
> > reclamaba clave duplicada!!!.. :S fue por eso ... pero bueno puede
> > que PG no sea asi ... era solo simple curiosidad
>
> Como dices, quién sabe que haya pasado - pero si llegaste a esa
> situación (tal vez insertando IDs a mano sin haberle pedido a
> Postgres que lo haga a través de la secuencia [...]

Entiendo que la mala experiencia la había tenido con SQL Server, no con
PostgreSQL. De todas formas, antes de tirarle tierra a SQL Server (no es esa
mi intensión), sospecho que eso le ocurrió independientemente del motor de
base de datos que haya utilizado. Le sucedió porque en lugar de dejar que el
motor administre las llaves primarias, él calculaba el valor en su aplicación
e intentaba insertar el registro ya con el valor de su llave.

> > Si pero = no se quiza soy un poco mas fundamentalista ... en ese
> > sentido prefiero tener el control como programador .. y no darle esa
> > responsabilidad al motor.. [...]

A ésto me refería.

> Me suena a que aprendiste a usar BDs con algo tipo MySQL, ¿verdad? Es
> mucho más confiable dejar que la BD lo haga. Si no, puedes caer
> fácilmente en condiciones de carrera - Por ejemplo, si tu programa
> incluye un SELECT id FROM articulos ORDER BY id DESC LIMIT 1 para
> encontrar si el ID más alto empleado, el cual es incrementado en 1, y
> después viene un INSERT INTO articulos (id, otros_campos) VALUES
>
> (el_nuevo_id, los_otros_valores) - ¿Qué pasa si llegan dos
> solicitudes a la vez? Recuerda que la comunicación con Postgres es
> via sockets, pues es entre dos procesos de sistema diferentes, e
> implica un cambio de contexto para el sistema operativo. Puedes
> terminar con una excepción por PK duplicada - A menos que implmentes
> un sistema de locking, semáforos o lo que gustes. ¡Ah! Olvidaba
> decírtelo: La buena gente de Postgres se tomó la molestia de
> implementarlo por tí. Se llama "secuencias" ;-)

Si no fué eso mismo lo que le ocurrió con SQL Server, debe haber pegado en el
palo. ¿Para qué reinventar la rueda?. Sobre todo cuando la rueda ofrecida por
PostgreSQL, es una circunferencia perfecta!. Saludos... ;)

-
-------------------------------------------
Sebastián Villalba
sebastian(at)fcm(dot)unc(dot)edu(dot)ar
-------------------------------------------

Sebastián Villalba escribió:
> Hola
>
> On Mon, 12 Nov 2007 11:29:30 -0600, Gunnar Wolf wrote
>
>>>>> diganme una cosa como se comportan esos campos en PG porque yo
>>>>> por norma siempre prefiero calcular el valor del campo cuando es
>>>>> una clave primaria porque me han pasado tallas en sqlserver al
>>>>> menos que esos campos a veces se corrompen
>>>>>
>>>> Nunca me paso. ¿Qué significa que se corrompe el campo? ¿En qué
>>>> forma se corrompe?
>>>>
>>> Es una larga historia!! pero por un motivo que no tengo la mas
>>> remota idea me calculo mal unas PK y al tratar de hacer un insert me
>>> reclamaba clave duplicada!!!.. :S fue por eso ... pero bueno puede
>>> que PG no sea asi ... era solo simple curiosidad
>>>
>> Como dices, quién sabe que haya pasado - pero si llegaste a esa
>> situación (tal vez insertando IDs a mano sin haberle pedido a
>> Postgres que lo haga a través de la secuencia [...]
>>
>
> Entiendo que la mala experiencia la había tenido con SQL Server, no con
> PostgreSQL. De todas formas, antes de tirarle tierra a SQL Server (no es esa
> mi intensión), sospecho que eso le ocurrió independientemente del motor de
> base de datos que haya utilizado. Le sucedió porque en lugar de dejar que el
> motor administre las llaves primarias, él calculaba el valor en su aplicación
> e intentaba insertar el registro ya con el valor de su llave.
>
>
>>> Si pero = no se quiza soy un poco mas fundamentalista ... en ese
>>> sentido prefiero tener el control como programador .. y no darle esa
>>> responsabilidad al motor.. [...]
>>>
>
> A ésto me refería.
>
>
>> Me suena a que aprendiste a usar BDs con algo tipo MySQL, ¿verdad? Es
>> mucho más confiable dejar que la BD lo haga. Si no, puedes caer
>> fácilmente en condiciones de carrera - Por ejemplo, si tu programa
>> incluye un SELECT id FROM articulos ORDER BY id DESC LIMIT 1 para
>> encontrar si el ID más alto empleado, el cual es incrementado en 1, y
>> después viene un INSERT INTO articulos (id, otros_campos) VALUES
>>
>>
No no aprendi con MySql nunca lo he usado .. aprendi con PG el año 2002
cuando hice mi tesis y despues trabaje 4 años con SqlServer...
>> (el_nuevo_id, los_otros_valores) - ¿Qué pasa si llegan dos
>> solicitudes a la vez? Recuerda que la comunicación con Postgres es
>> via sockets, pues es entre dos procesos de sistema diferentes, e
>> implica un cambio de contexto para el sistema operativo. Puedes
>> terminar con una excepción por PK duplicada - A menos que implmentes
>> un sistema de locking, semáforos o lo que gustes. ¡Ah! Olvidaba
>> decírtelo: La buena gente de Postgres se tomó la molestia de
>> implementarlo por tí. Se llama "secuencias" ;-)
>>
>
>
sip entiendo por hay iva mi pregunta ... en base a su experiencia como
se comportan... ahora me queda mas claro.

> Si no fué eso mismo lo que le ocurrió con SQL Server, debe haber pegado en el
> palo. ¿Para qué reinventar la rueda?. Sobre todo cuando la rueda ofrecida por
> PostgreSQL, es una circunferencia perfecta!. Saludos... ;)
>
Nop eso no fue lo que ocurrio con SqlServer .. por eso preguntaba en el
inicio del correo como se comportaban estos campos en PG...
> -
> -------------------------------------------
> Sebastián Villalba
> sebastian(at)fcm(dot)unc(dot)edu(dot)ar
> -------------------------------------------
>
>

Slds.
Javier

Antes que todo, un agradecimiento especial, a las personas que aportaron a esta inquietud. De otro lado, ofrecer disculpas, por hasta ahora reportarme al respecto. La conclución que saque al respecto, es que pese a que es posible la actualización en cascada, me parece una operación muy riesgoza, sobre todo si uno está en modo consola... un (delete... mal hecho... y sin la protección de llaves foraneas... puede terminar con medio modelo...)

Respecto a la técnica de diseño de aplicaciones con campos seriales, creo que viene muy bién a mi caso, sobre todo si el DNI, o documento de identidad (acá en Colombia), es único e irrepetible, me permite establecerlo como único pero sin ser llave.

Agradezco sus valiosos aportes, y espero ponerlos epráctica... me costará un montón de trabajo, pero más vale tarde que nunca

Saludos a todos y mil gracias...

Sebastián Villalba <sebastian(at)fcm(dot)unc(dot)edu(dot)ar> escribió: On Fri, 9 Nov 2007 21:25:32 -0300, usuario anonimo wrote
> El 9/11/07, Sebastián Villalba escribió:
> > On Fri, 9 Nov 2007 15:12:54 -0800 (PST), WILLIAM PARRA wrote
> > > Buenas tardes compañeros.
> >
> > Hola William...
> >
> > > Necesito que por favor me den luces, de como resolver de la mejor
> > > manera la siguiente situación: Debo actualizar un registro, más
> > > exactamente el documento de una persona, el cual es la llave
> > > primaria de una tabla de inscritos. Esa tabla, tiene registros
> > > relacionados en tablas hija.
> >
> > Es una mala idea de diseño que un documento sea una llave primaria. Pueden
>
> a que se refieren con un "documento" ? un archivo guardado en un
> campo de un registro ?

Oops!. Que buena pregunta.

Yo lo había interpretado a lo que aquí en Argentina llamamos "DNI" (Documento
Nacional de Identidad). A eso me refería cuando dije que pueden haber de
varios tipos (Cédulas de identidad, Pasaportes e inclusive se sabe que aquí en
Argentina hay números repetidos).

Por el contexto como lo escribió el amigo William, ni se me ocurrió pensar en
otro tipo de documentos (archivos electrónicos por ejemplo), pero honestamente
creo que se refiere a mi primer interpretación. William es la persona indicada
para salvar la duda. Saludos...

-
-------------------------------------------
Sebastián Villalba
sebastian(at)fcm(dot)unc(dot)edu(dot)ar
-------------------------------------------
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

William Enrique Parra Alba
Ingeniero De Sistemas
Universidad Pedagógica y Tecnológica de Colombia
/\ /\
/ //\\ \
\ \\// /
/ / \ \
\/ \/

---------------------------------

Comparte video en la ventana de tus mensajes (y también tus fotos de Flickr).
Usa el nuevo Yahoo! Messenger versión Beta.
Visita http://e1.beta.messenger.yahoo.com/