Skip site navigation (1) Skip section navigation (2)

Re: Consulta SQL

From: Alejandro Carrillo <fasterzip(at)yahoo(dot)es>
To: Alexis Camue <acamue(at)estudiantes(dot)uci(dot)cu>, "Ivan Perales M(dot)" <ivan(dot)perales(at)gmail(dot)com>
Cc: Ayuda Esp PostgreSQL <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Consulta SQL
Date: 2012-05-22 13:24:32
Message-ID: 1337693072.33664.YahooMailNeo@web171003.mail.ukl.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
Te vuelvo a repetir la respuesta COMPLETA:

1) Te recomiendo no tomes este hilo para hacer esta pregunta. Crea uno nuevo y publicalo en la lista.
2) Si todas las tablas tienen triggers(es decir, cuando borras las padre 
se activa el trigger que alamcena cada tabla hija en el log), podrías 
crear una function que recupere la info que esté borrada, teniendo en 
cuenta las relaciones ACTUALES EN EL MODELO DE LA BD.


Para consultar las tablas que son hijas de la tabla padre:
SELECT
    tc.constraint_name, tc.table_name, kcu.column_name, 
    ccu.table_name AS NOMBRETABLAFORANEA,
    ccu.column_name AS NOMBRECOLFORANEA 
    ,CCU.*
FROM 
    information_schema.table_constraints AS tc 
    JOIN
 information_schema.key_column_usage AS kcu ON tc.constraint_name = kcu.constraint_name
    JOIN information_schema.constraint_column_usage AS ccu ON ccu.constraint_name = tc.constraint_name
WHERE constraint_type = 'FOREIGN KEY' AND ccu.table_name='clientes' AND CCU.TABLE_SCHEMA ='public' ;

Tomado de: http://stackoverflow.com/questions/1152260/postgres-sql-to-list-table-foreign-keys 
Modifique para que permitiera consultar por schemas.

ó

SELECT fkn.nspname AS fk_namespace, fkr.relname AS fk_relation, fka.attname AS fk_column, fka.attnotnull AS fk_notnull,
 (EXISTS
 (SELECT pg_index.indexrelid, pg_index.indrelid, pg_index.indkey, 
pg_index.indclass, pg_index.indnatts, pg_index.indisunique, 
pg_index.indisprimary, pg_index.indisclustered, pg_index.indexprs, 
pg_index.indpred FROM pg_index WHERE ((pg_index.indrelid = fkr.oid) AND 
(pg_index.indkey[0] =
 fka.attnum)))) AS fk_indexed,
  pkn.nspname AS pk_namespace, pkr.relname AS pk_relation, pka.attname AS pk_column, 
 
 (EXISTS (SELECT pg_index.indexrelid, pg_index.indrelid, 
pg_index.indkey, pg_index.indclass, pg_index.indnatts, 
pg_index.indisunique, pg_index.indisprimary, pg_index.indisclustered, 
pg_index.indexprs, pg_index.indpred FROM pg_index WHERE 
((pg_index.indrelid = pkr.oid) AND (pg_index.indkey[0] = pka.attnum)))) 
AS pk_indexed, 
  ((c.confupdtype)::text || (c.confdeltype)::text) AS ud, cn.nspname AS c_namespace, c.conname AS c_name 
 
 FROM (((((((pg_constraint c JOIN pg_namespace cn ON ((cn.oid = 
c.connamespace))) JOIN pg_class fkr ON ((fkr.oid = c.conrelid))) 
  
JOIN pg_namespace fkn ON ((fkn.oid = fkr.relnamespace))) JOIN 
pg_attribute fka ON (((fka.attrelid = c.conrelid) AND (fka.attnum = ANY 
(c.conkey))))) 
  JOIN pg_class pkr ON ((pkr.oid = c.confrelid))) JOIN pg_namespace pkn ON ((pkn.oid =
 pkr.relnamespace))) JOIN pg_attribute pka ON (((pka.attrelid = c.confrelid) 
  AND (pka.attnum = ANY (c.confkey))))) WHERE (c.contype = 'f'::"char") and pkn.nspname ='public' and pkr.relname ='clientes';

Tomado de: http://code.google.com/p/pgutils/downloads/list 

Modifique para que permitiera consultar por schema y tabla.

La solución sería: Cuando se recupere una tabla 
padre, se deben recuperar todos los registros de las tablas hijas. Para 
saber cuales son las tablas hijas, ahi estan las consultas. Aunque 
podrías hacer la inversa para recuperar un registro, verifique las 
tablas padre de esta tabla y recupere esos registros de ls tablas padre y luego recupere el registro de la tabla hija.

Cuidate



________________________________
 De: Alexis Camue <acamue(at)estudiantes(dot)uci(dot)cu>
Para: Alejandro Carrillo <fasterzip(at)yahoo(dot)es> 
Enviado: Domingo 20 de Mayo de 2012 0:08
Asunto: Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Efectuar copy desde un archivo con más columnas que la tabla
 
Buenas le escribo porque tengo una duda  con postgres:


Le explico mi problema:
Tengo hecha una aplicación que controla las
operaciones (INSERT, UPDATE, DELETE) realizadas en una base de datos
postgreSQL a travéz de triggers. Todos estos datos son guardados en
tablas de manera tal que en esa base datos no se pierda información y
que el usuario pueda recuperarla cuando desee. Ej: Un usuario borra de
una tabla PERSONA a la PERSONA(id=1, nombre =alejandro), estos datos a
travéz de triggers se guardan en una tabla creada con anterioridad
llamada PERSONA_delete, si el usuario quiere deshacer esta acción,
selecciona desde la aplicación este registro guardado y lo recupera (La
aplicación se encarga de hacer esto a travéz de una consulta insert).
Esto me funciona perfecto en una base de datos con tablas NO
RELACIONADAS pero cuando voy a recuperar una entidad que pertenece a
una tabla X que presenta una relación z con la tabla Y, postgre me
envia error de primary key, forein key etc. Pienso que esto tenga que
ver con borrar e insertar en CASCADA, pero desconozco como funciona
este proceso y no he podido encontrar una bibliografia o pagina donde
se explique este proceso para poder automatizarlo (si se puede) tiene usted alguna idea de como es__???. 

Le agradecería cualquier contribución al respecto.


saludos



"Quien quiere hacer busca medios...quien no quiere hacer busca justificaciones"
"Cada persona desconocida, es un amigo esperando por ti"
                                     

                                    Alexis Camué Hernandez
                                       apto:  102 206
                                       Telf: (837)2926
                            
  Universidad de Ciencias Informáticas



>________________________________
> De: Alexis Camue <acamue(at)estudiantes(dot)uci(dot)cu>
>Para: Ivan Perales M. <ivan(dot)perales(at)gmail(dot)com> 
>CC: Ayuda Esp PostgreSQL <pgsql-es-ayuda(at)postgresql(dot)org> 
>Enviado: Lunes 21 de Mayo de 2012 13:12
>Asunto: [pgsql-es-ayuda] Consulta SQL
> 
>
>Buenas lista: 
>Me pueden ayudar con alguna consulta que dada una tabla A me devuelva el nombre de las tablas que se relacionan con esta, por supuesto, en el caso que no tenga relaciones no devuelve nada.
>Gracias de antemano...
>
>
>
>"Quien quiere hacer busca medios...quien no quiere hacer busca justificaciones"
>"Cada persona desconocida, es un amigo esperando por ti"
>                                     
>
>                                    Alexis Camué Hernandez
>                                       apto:  102 206
>                                       Telf: (837)2926
>                              Universidad de Ciencias Informáticas
>
>________________________________
>
>De: "Ivan Perales M." <ivan(dot)perales(at)gmail(dot)com>
>Para: "Ayuda Esp PostgreSQL" <pgsql-es-ayuda(at)postgresql(dot)org>
>Enviados: Lunes, 21 de Mayo 2012 13:13:03
>Asunto: [pgsql-es-ayuda] Substring en bytea
>
>
>Hola lista buen día, acudo a ustedes por la siguiente cuestión.
>Estoy trabajando con java, en una columna de tipo bytea inserto los datos binarios de archivos adjuntos, se que no es Lo mejor pero por el momento es Lo que tenemos. En está columna voy agregando la información con algo como data = data ¦¦ :newdata. Esto funciona bien ya que al hacer un length me devuelve los bytes del tamaño del archivo. 
>Pero cuando trato de obtener la información con un substring, supongamos de 
>100 kb, substring(data from 1 for 102400) en postgres me devuelve los 100 kb exactos, pero en java obtengo un array como de 199 kb y esto pues ya es erróneo. 
>Tendrá algo que ver que la bd este en utf? O sí no, conocen alguna herramienta para leer de forma exadecimal el valor de un byeta y comparar contra Lo que obtengo en java?
>Saludos y de antemano gracias
>Solo existen 10 tipos de personas en el mundo, las que saben binario y las que no.
>
> 
>
>
>

In response to

Responses

pgsql-es-ayuda by date

Next:From: Alejandro CarrilloDate: 2012-05-22 13:30:38
Subject: Re: Consumir TXT Tabulado de Oracle para Postgresql
Previous:From: Dario Andres Almonte AlonzoDate: 2012-05-21 20:18:01
Subject: Re: Roles en postgres 8.3

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group