Re: problema orden comprobación integridad

From: Linos <info(at)linos(dot)es>
To:
Cc: Lista PostgreSql <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: problema orden comprobación integridad
Date: 2008-10-03 07:12:33
Message-ID: 48E5C5E1.8010905@linos.es
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Moises Alberto Lindo Gutarra escribió:
> El día 2 de octubre de 2008 16:54, Linos <info(at)linos(dot)es> escribió:
>> Moises Alberto Lindo Gutarra escribió:
>>> 2008/10/2 Linos <info(at)linos(dot)es>:
>>>> Hola, les explico mi problema, uso postgresql 8.3.3 con una base de datos
>>>> en
>>>> UTF8, el esquema de la tabla es esta:
>>>>
>>>> CREATE TABLE bulto_cabecera
>>>> (
>>>> id_documento integer NOT NULL,
>>>> bulto_id integer NOT NULL,
>>>> numero_bulto_documento integer NOT NULL,
>>>> time_stamp timestamp with time zone DEFAULT now(),
>>>> id_usuario integer NOT NULL,
>>>> completo boolean NOT NULL,
>>>> tipo_origen character varying(32) NOT NULL,
>>>> CONSTRAINT albaran_salida_bultos_cab_pkey PRIMARY KEY (bulto_id),
>>>> CONSTRAINT bulto_cabecera_id_documento_key UNIQUE (id_documento,
>>>> numero_bulto_documento)
>>>> )
>>>> WITH (OIDS=FALSE);
>>>> ALTER TABLE bulto_cabecera OWNER TO skuda;
>>>>
>>>> cuando intento insertar una fila ya existente no siempre me da el error
>>>> sobre la clave primaria si no q a veces salta el indice único, fijense
>>>> por
>>>> ejemplo.
>>>>
>>>> skuda=# INSERT INTO bulto_cabecera(id_documento, bulto_id,
>>>> numero_bulto_documento, time_stamp, id_usuario, completo, tipo_origen)
>>>> VALUES ('2000244341'::integer, '2000244343'::integer, '2'::integer,
>>>> 'now()'::timestamp with time zone, '2102'::integer, FALSE::boolean,
>>>> 'ALBARAN_SALIDA'::text)
>>>> skuda-# ;
>>>> ERROR: duplicate key value violates unique constraint
>>>> "albaran_salida_bultos_cab_pkey"
>>>> skuda=# \q
>>>>
>>>> skuda(at)skuda ~/temporal/ficheros_sql $ psql -d skuda
>>>> Welcome to psql 8.3.3, the PostgreSQL interactive terminal.
>>>>
>>>> Type: \copyright for distribution terms
>>>> \h for help with SQL commands
>>>> \? for help with psql commands
>>>> \g or terminate with semicolon to execute query
>>>> \q to quit
>>>>
>>>> skuda=# INSERT INTO skuda.bulto_cabecera(id_documento, bulto_id,
>>>> numero_bulto_documento, time_stamp, id_usuario, completo, tipo_origen)
>>>> VALUES ('2000244341'::integer, '200024434'::integer, '2'::integer,
>>>> 'now()'::timestamp with time zone, '2102'::integer, FALSE::boolean,
>>>> 'ALBARAN_SALIDA'::text);
>>>> ERROR: duplicate key value violates unique constraint
>>>> "bulto_cabecera_id_documento_key"
>>>>
>>>> La verdad es q normalmente no me importaría (una fila no valida es mala
>>>> sea
>>>> el motivo q sea) pero el problema es q la solución para la replicación
>>>> que
>>>> estoy usando se basa en un sistema de callback si el registro ya existe
>>>> que
>>>> lo pasa a un update y claro se base en error de clave primaria el
>>>> callback,
>>>> como aquí el error es un indice único me bloquea los canales de
>>>> replicacion
>>>> con un error, por que sucede esto? puedo hacer q siempre salte el error
>>>> sobre la clave primaria sin borrar el indice único?
>>>>
>>>> Gracias y un saludo,
>>>> Miguel Angel.
>>>> --
>>>> TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
>>>>
>>> Creo que esta demas el
>>> CONSTRAINT bulto_cabecera_id_documento_key UNIQUE (id_documento,
>>> numero_bulto_documento)
>>> ya que siempre se dará esta regla con la pk.
>>>
>>>
>>>
>> en correcto esta regla si pero esa comprobación de integridad me puede ser
>> útil si hay un fallo en la aplicación por ejemplo, se supone que no deberían
>> poder meter para el mismo documento, el mismo numero de bulto dos veces, de
>> todas maneras no debería saltar siempre primero la clave primaria?
>> --
>> TIP 4: No hagas 'kill -9' a postmaster
>>
>
> eso jamas va a suceder, ni el mismo nro de bulto ni ninguno con el
> documento ya que el documento id es la PK. Quita ese constraint.
>

Moises si que podría pasar te explico una secuencia sencilla de pasos que
llevarían a ese problema, estos son los bultos de albaranes de salida y hay
varios ordenadores de almacén, el bulto_id es una secuencia automática aunque no
se vea ahí en el schema con lo cual no guarda una relación directa ni con el
numero de documento ni con el numero de bulto para ese documento (un surrogate
key vaya, suelo usarlas para evitar multicolumnas en los joins habitualmente),
si dos empleados de almacén se ponen a asignarle bultos de salida a un albarán
al mismo tiempo puede suceder perfectamente q creen el mismo numero de bulto
para el mismo documento con un bulto_id diferente (bulto_id: 119541, documento:
305, numero_bulto_doc: 1), o sea q el constraint es valido, otra cosa q podría
hacer es pasar la clave primaria a esas dos columnas y dejar el bulto_id como un
indice único con el q hacer los joins, pero de todas maneras lo q estaba
interesado en saber no es si el diseño es valido, si no si es normal q esto
suceda así (que de manera random o eso parece elija con que constraint negar la
inserción de la nueva fila)

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Oswaldo Hernández 2008-10-03 09:22:36 Re: problema orden comprobación integridad
Previous Message Ernesto Lozano 2008-10-03 03:14:43 Re: pgday buenos aires