RE: Actualizacion en Cascada de llave primaria

From: "Patricio Cifuentes Ithal" <pcifuentes(at)siigsa(dot)cl>
To: "'Alvaro Herrera'" <alvherre(at)commandprompt(dot)com>, "'WILLIAM PARRA'" <wilparra(at)yahoo(dot)com>
Cc: <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: RE: Actualizacion en Cascada de llave primaria
Date: 2007-11-12 14:20:27
Message-ID: 005201c82537$2d0461b0$870d2510$@cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

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

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message ML 2007-11-12 14:29:09 Re: Actualizacion de 8.2.5 a 8.3
Previous Message Alvaro Herrera 2007-11-12 14:10:08 Re: Actualizacion de 8.2.5 a 8.3