Re: [pgsql-es-ayuda] Compilar Postgresql sin OpenSSL con LibreSSL u otra similar
On Thu, 11 Feb 2016 13:42:50 -0300 Alvaro Herrera wrote: > Eduardo Morras escribió: > > > No, puede que no me haya explicado bien, el cliente SI quiere > > SSL/TLS, pero no la implementacion de OpenSSL. Las aplicaciones > > usan LibreSSL, > > modificando /postgresql/src/interfaces/libpq/fe-secure-openssl.c y > > cambiado de nombre a fe-secure-libressl.c para que compile con > > libressl (cambios minimos, ya que tiene modo de compatibilidad con > > openssl) > > > > Las dos opciones que tengo en mente, son: > > > > a) Compilar PostgreSQL con LibreSSL u otra implementacion, como > > mbedtls/polarssl o nss. > > b) Poner en la misma maquina que el servidor pgbouncer, compilado > > con LibreSSL. Las conexiones de los clientes a pgbouncer son > > seguras y entre pgbouncer y PostgreSQL no creo que hagan falta al > > compartir maquina. > > Heikki Linnakangas inició hace un par de años un proyecto para > permitir que Postgres sea "agnóstico a la implementación SSL", de > manera que se puedan usar otras bibliotecas como LibreSSL, GnuTLS, > Schannel (Windows), Mozilla NSS, para la implementación subyacente. > Lo que está hecho hasta el momento es que la parte de OpenSSL está > encapsulada en ese archivo be-secure-openssl.c; lo que falta es > permitir que otras bibliotecas ofrezcan una API similar para poder > tener be-secure-schannel.c etc. Ahh..., entonces tambien hay que modificar el src/backend/libpq? Solo estaba modificando el src/interfaces/libpq. Supongo que uno sera para el servidor y el otro para clientes. > La gracia de LibreSSL es que es muy similar a OpenSSL y debería ser > posible crear un be-secure-libressl.c a partir del -openssl.c sin > demasiado trabajo. Si lo haces, quizás podrías considerar la idea de > transformar eso en un parche para Postgres y enviarlo a pg-hackers. > En cambio, hacerlo con PolarSSL o alguna de las otras deber ser un > esfuerzo mucho mayor (y por lo tanto si lo haces, definitivamente > envía el parche a -hackers). Son muy similares, en muchos proyectos basta con cambiar el makefile ya que la API de LibreSSL tiene un modo de compatibilidad 100%. Esta parte del proyecto he conseguido ponerla bajo licencia tipo BSD o similar (Mit,Isc, Postgresql, BSD2-clause, x11..) como pago por el uso de Postgresql. > BTW tengo entendido que SSL incluso en SSLv3 tiene problemas de > seguridad bastante severos, y sólo TLS v1.2 debería considerarse > ahora. De hecho en fe-secure-openssl.c sslv2 y sslv3 estan deshabilitados. Hay comentarios en el codigo que explican que no son seguros y que solo se usa TLS. Muchas gracias > -- > Álvaro Herrerahttp://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > --- --- Eduardo Morras - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] [OFFTOPIC] - Espacio en disco de tablas con imágenes.
On Thu, 11 Feb 2016 18:20:35 -0300 Alvaro Herrera wrote: > > (*) en realidad, comparado con los nuevos algoritmos, no es tan rápido > tampoco :-( Perdon por la intromision en el hilo. Yo he trabajado con algoritmos de compresion de datos (texto, video e imagenes, datos binarios...). Que requisitos (aparte de la licencia y portabilidad) deberia tener un sustituto? Orientado a bloques/blocks (bzip) o a flujo/stream (zlib)? Cuanta cpu puede gastar? Un saludo --- --- Eduardo Morras - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] RE: [pgsql-es-ayuda] [OFFTOPIC] - Espacio en disco de tablas con imágenes.
> El 11/02/16 a las 21:36, Mario Soto Cordones escribió: > No creo que sea buena alternativa guardar los documentos digitalizados en la base de datos Sin generar enfrentamientos, creo que sí se pueden almacenar objetos largos como imágenes en base de datos, y que en ciertas situaciones es totalmente aconsejado. Según https://wiki.postgresql.org/wiki/BinaryFilesInDB : > When is it bad idea to store binary files in the database? > Very large files (100meg+), where performance is critical to the application. The database layer adds a lot of overhead and complexity that may not be required. El tratamiento que Postgres hace a los tipos de datos BLOB es muy diferente al del resto de tipos de datos, haciendo conveniente su uso cuando existe una fuerte dependencia entre el dato (ejemplo imagen) y conjunto de metadatos o atributos de la relación. Un saludo. El 11/02/16 a las 21:36, Mario Soto Cordones escribió: > Hola Mario: > > No creo que sea buena alternativa guardar los documentos digitalizados en la > base de datos, ahora bien nada es absoluto, si el volumen de documentos, es > bajo, entonces no creo que exista problema. Ahora bien, respecto a la base de > datos en sí, debes tener conciencia de lo que implica tener tablas con tipos > de datos bytea (por el tamaño propiamente tal) ya que generan TOAST. > > Saludos > > Mario Soto > > -Mensaje original- > De: pgsql-es-ayuda-ow...@postgresql.org > [mailto:pgsql-es-ayuda-ow...@postgresql.org] En nombre de "Mario Jiménez > Carrasco (isccarrasco)" > Enviado el: jueves, 11 de febrero de 2016 16:29 > Para: pgsql-es-ayuda@postgresql.org > Asunto: [pgsql-es-ayuda] [OFFTOPIC] - Espacio en disco de tablas con imágenes. > > Buen día comunidad. > > El presente es un cuestionamiento que posiblemente ya han tocado en este > foro, pero he revisado y tengo algunas dudas puntuales. > > > En la empresa donde laboro, tenemos actualmente una aplicación en la que se > digitaliza documentos que son cargados directamente a la base de datos como > objetos tipo batea, el primer cuestionamiento sería: > ¿Es recomendable hacer esto?, o ¿Cuál sería el mecanismo mas recomendable? > > Por otro lado veo que el tamaño de la base de datos ha crecido (obvio por las > imágenes), el cuestionamiento en este caso sería, ¿Existe algún plugin de > PostgreSQL que comprima las imágenes sin perder la calidad? o ¿este un tema > del lado de la aplicación?. > > Si tuvieran algún dato o referencia documental donde poder guiarme, o sus > opiniones, son bien recibidas. > > Agradezco de antemano el apoyo. > > > > - > Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) > Para cambiar tu suscripci n: > http://www.postgresql.org/mailpref/pgsql-es-ayuda > > > - > Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) > Para cambiar tu suscripci�n: > http://www.postgresql.org/mailpref/pgsql-es-ayuda - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] [OFFTOPIC] - Espacio en disco de tablas con imágenes.
Eduardo Morras escribió: > On Thu, 11 Feb 2016 18:20:35 -0300 > Alvaro Herrera wrote: > > > > > (*) en realidad, comparado con los nuevos algoritmos, no es tan rápido > > tampoco :-( > > Perdon por la intromision en el hilo. Yo he trabajado con algoritmos de > compresion de datos (texto, video e imagenes, datos binarios...). Que > requisitos (aparte de la licencia y portabilidad) deberia tener un sustituto? > > Orientado a bloques/blocks (bzip) o a flujo/stream (zlib)? > Cuanta cpu puede gastar? En realidad esas no son las preguntas que tenemos pendientes ahora. Esas que propones ya se han discutido, y algoritmos como lz4 y Snappy otros se han mencionado varias veces. El problema pendiente es cómo permitir nuevos algoritmos de compresión en el sistema. Mira por ejemplo este hilo: http://www.postgresql.org/message-id/flat/20130614230142.gc19...@awork2.anarazel.de y quizás este: https://www.postgresql.org/message-id/CAPpHfdsdTA5uZeq6MNXL5ZRuNx%2BSig4ykWzWEAfkC6ZKMDy6%3DQ%40mail.gmail.com -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Compilar Postgresql sin OpenSSL con LibreSSL u otra similar
Eduardo Morras escribió:
> On Thu, 11 Feb 2016 13:42:50 -0300
> Alvaro Herrera wrote:
>
> > Heikki Linnakangas inició hace un par de años un proyecto para
> > permitir que Postgres sea "agnóstico a la implementación SSL", de
> > manera que se puedan usar otras bibliotecas como LibreSSL, GnuTLS,
> > Schannel (Windows), Mozilla NSS, para la implementación subyacente.
> > Lo que está hecho hasta el momento es que la parte de OpenSSL está
> > encapsulada en ese archivo be-secure-openssl.c; lo que falta es
> > permitir que otras bibliotecas ofrezcan una API similar para poder
> > tener be-secure-schannel.c etc.
>
> Ahh..., entonces tambien hay que modificar el src/backend/libpq? Solo
> estaba modificando el src/interfaces/libpq. Supongo que uno sera para
> el servidor y el otro para clientes.
Hm, sí, justamente.
> > La gracia de LibreSSL es que es muy similar a OpenSSL y debería ser
> > posible crear un be-secure-libressl.c a partir del -openssl.c sin
> > demasiado trabajo. Si lo haces, quizás podrías considerar la idea de
> > transformar eso en un parche para Postgres y enviarlo a pg-hackers.
> > En cambio, hacerlo con PolarSSL o alguna de las otras deber ser un
> > esfuerzo mucho mayor (y por lo tanto si lo haces, definitivamente
> > envía el parche a -hackers).
>
> Son muy similares, en muchos proyectos basta con cambiar el makefile
> ya que la API de LibreSSL tiene un modo de compatibilidad 100%. Esta
> parte del proyecto he conseguido ponerla bajo licencia tipo BSD o
> similar (Mit,Isc, Postgresql, BSD2-clause, x11..) como pago por el uso
> de Postgresql.
OK. Después de dormir me pregunto si será realmente necesario crear un
archivo -libressl.c o bastará con algún retoque en el Makefile para que
lo considere (y quizás agregar algún #ifdef en los casos en que la API
provista sea distinta).
Por el momento todavía tenemos configure --enable-openssl. Yo me
imagino que lo que sucederá en el futuro cuando tengamos alguna otra
implementación para TLS es que esa opción se cambiará a algo como
--enable-tls={openssl,libressl}
lo cual seleccionaría automágicamente el (o los) archivos correctos a
compilar, algún "define" en pg_config.h, etc.
> > BTW tengo entendido que SSL incluso en SSLv3 tiene problemas de
> > seguridad bastante severos, y sólo TLS v1.2 debería considerarse
> > ahora.
>
> De hecho en fe-secure-openssl.c sslv2 y sslv3 estan deshabilitados.
> Hay comentarios en el codigo que explican que no son seguros y que
> solo se usa TLS.
Ah, cierto.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
[pgsql-es-ayuda] Calculo de dígito verificador EAN13 mediante sql
Buen día.
Tengo el siguiente sql para calcular el dígito verificador de EAN13.
With t AS ( Select s.numero::INTEGER, ROW_NUMBER() OVER () rwn From ( Select
regexp_split_to_table('7861091605917', E'[^0-9]*') as numero) s ), vAS(
Select sum(t.numero * CASE WHEN mod(rwn, 2) = 0 THEN 3 ELSE 1 END) As total
From t Where rwn <= 12) SELECT CASE WHEN mod(v.total, 10) = 0 Then 0 ELSE 10
- Mod(v.total, 10) END AS digito_verificador From v;
Mi duda es si la función regexp_split_to_table va a respetar el orden de string
para que row_number() lo numere y no tener problemas en el calculo, que depende
de la posición de cada dígito.
Estoy por crear una función con este código, la cual va a ser llamada
esporádicamente. Saludos.Mauricio
Re: [pgsql-es-ayuda] Calculo de dígito verificador EAN13 mediante sql
On 02/12/2016 02:54 PM, mauricio pullabuestan wrote:
Buen día.
Tengo el siguiente sql para calcular el dígito verificador de EAN13.
Has mirado la documentación de la extensión ISN?
En cualquier caso, yo lo implementaría a golpe de PL/PgSQL, no en SQL
puro con CTEs
With t
AS
(
Select s.numero::INTEGER, ROW_NUMBER() OVER () rwn
From
(
Select
regexp_split_to_table('7861091605917', E'[^0-9]*') as numero
) s
), v
AS
(
Select sum(t.numero * CASE WHEN mod(rwn, 2) = 0 THEN 3 ELSE 1 END) As
total
From t
Where rwn <= 12
)
SELECT CASE WHEN mod(v.total, 10) = 0 Then 0 ELSE 10 - Mod(v.total,
10) END AS digito_verificador
From v;
Mi duda es si la función regexp_split_to_table va a respetar el orden
de string para que row_number() lo numere y no tener problemas en el
calculo, que depende de la posición de cada dígito.
Estoy por crear una función con este código, la cual va a ser llamada
esporádicamente.
Razón de más para hacerlo en PL/PgSQL.
HTH,
/ Jose
[pgsql-es-ayuda] Permisos por default para un "Rol de Grupo".
Gente, Hola!. Les consulto si lo siguiente puede ser realizado. Yo quiero asignar un conjunto de permisos por default para un Rol de Grupo (sin permiso de login) y esquema. De esta forma me gustaría que, por ejemplo, cuando un usuario perteneciente a este grupo cree una tabla en este esquema la misma tenga permisos de select para un grupo, select, update, insert y delete para otro. Intenté los suguiente, según leí en la doc, pero evidentemente entendí algo mal porque no funciona. CREATE ROLE dbaprueba_esquema1_adm NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION; CREATE ROLE dbaprueba_esquema1_app NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION; CREATE ROLE dbaprueba_esquema1_select NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION; REATE ROLE dbaprueba_esquema1_dba LOGIN ENCRYPTED PASSWORD 'md50de1f0189c89f8355e43208aa39971de' NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION; ALTER ROLE dbaprueba_esquema1_dba SET search_path = esquema1, public; GRANT dbaprueba_esquema1_adm TO dbaprueba_esquema1_dba; alter default privileges for role dbaprueba_esquema1_adm in schema esquema1 grant select on tables to dbaprueba_esquema1_select; alter default privileges for role dbaprueba_esquema1_adm in schema esquema1 grant select, insert, update, delete on tables to dbaprueba_esquema1_app; Luego me gustaría que si el usuario dbaprueba_esquema1_dba crea una tabla en esquema1, por ejemplo: create table nn (); Le agregue automáticamente los permisos: GRANT SELECT ON TABLE esquema1.nn TO dbaprueba_esquema1_select; GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE esquema1.nn TO dbaprueba_esquema1_app; Saludos y gracias de antemano. Federico.
[pgsql-es-ayuda] Re: [pgsql-es-ayuda] [OFFTOPIC] - Espacio en disco de tablas con imágenes.
Buen día Alvaro… El punto que mencionas es precisamente lo que nos llevó a utilizar inicialmente el mecanismo de cargar las imágenes y/o documentos a la base de datos; la de poder tener toda la información disponible desde la misma base y al moverse no tener que estar haciendo otras copias, sin embargo ahora nos preocupa el tema de que la base de datos se ha vuelto muy pesada, y pensamos que tal vez había formas más eficientes de manejar este detalle… Entre las propuestas que estamos analizando en el equipo son: 1. Manejar un directorio de almacenamiento en el servidor en el cual se almacenen los datos con una estructura definida por la aplicación. 2. Crear una base de datos alterna únicamente para el tema de documentos digitalizados y desde la aplicación hacer la conexión a ambas bases para almacenar los documentos y/o la información referente a la aplicación. Aun estamos definiendo este tema, pero su apoyo y comentarios no han servido de mucho… Gracias. Saludos. > El 11/02/2016, a las 3:20 p.m., Alvaro Herrera > escribió: > > "Mario Jiménez Carrasco (isccarrasco)" escribió: > >> En la empresa donde laboro, tenemos actualmente una aplicación en la >> que se digitaliza documentos que son cargados directamente a la base >> de datos como objetos tipo batea, el primer cuestionamiento sería: ¿Es >> recomendable hacer esto?, o ¿Cuál sería el mecanismo mas recomendable? > > Hacerlo de esa forma funciona bien. Sobre todo, considera que si pones > los archivos fuera de la BD necesitarás considerarlas separadamente en > caso que quieras hacer respaldos y tener réplicas. Si lo pones todo en > la BD y manejas replicación streaming (o cualquier otro tipo de > replicación, en realidad), tus servidores réplica automáticamente > tendrán toda la información sin tener que preocuparte de un mecanismo > adicional para copiar los archivos. > > La BD será más pesada, obviamente, pero si no tienes el "peso" en la BD > entonces tendrás que tenerlo en otra parte, y no necesariamente estarás > en mejor pie. ¿O estás pensando en usar un sistema de archivos en red, > como LustreFS etc? > >> Por otro lado veo que el tamaño de la base de datos ha crecido (obvio >> por las imágenes), el cuestionamiento en este caso sería, ¿Existe >> algún plugin de PostgreSQL que comprima las imágenes sin perder la >> calidad? o ¿este un tema del lado de la aplicación?. > > Si el campo es grande, Postgres intenta aplicar compresión usando un > algoritmo relativamente rápido(*) pero no muy bueno. Si el formato es PDF, > JPEG o similar, que ya tienen compresión interna, es inútil que la BD > trate de comprimir de nuevo. En esos casos es mejor usar ALTER TABLE > SET STORAGE para que la columna se guarde sin intentar la compresión. > Si estás guardando texto ASCII o grandes documentos XML (que de por sí > son bastante compresibles), normalmente la compresión es buena idea; si > no, no. > > (*) en realidad, comparado con los nuevos algoritmos, no es tan rápido > tampoco :-( > > -- > Álvaro Herrerahttp://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
[pgsql-es-ayuda] RE: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] [OFFTOPIC] - Espacio en disco de tablas con imágenes.
Hola Sin embargo, lo que indica Alvaro es un buen punto sobre todo si estás realizando replicación, ya que no podrás replicar los documentos digitalizados sino están almacenados en la base de datos. En fin, creo que ya tienes más opciones para poder tomar una decisión. Saludos -Mensaje original- De: pgsql-es-ayuda-ow...@postgresql.org [mailto:pgsql-es-ayuda-ow...@postgresql.org] En nombre de "Mario Jiménez Carrasco (isccarrasco)" Enviado el: viernes, 12 de febrero de 2016 14:39 Para: Alvaro Herrera CC: pgsql-es-ayuda@postgresql.org Asunto: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] [OFFTOPIC] - Espacio en disco de tablas con imágenes. Buen día Alvaro… El punto que mencionas es precisamente lo que nos llevó a utilizar inicialmente el mecanismo de cargar las imágenes y/o documentos a la base de datos; la de poder tener toda la información disponible desde la misma base y al moverse no tener que estar haciendo otras copias, sin embargo ahora nos preocupa el tema de que la base de datos se ha vuelto muy pesada, y pensamos que tal vez había formas más eficientes de manejar este detalle… Entre las propuestas que estamos analizando en el equipo son: 1. Manejar un directorio de almacenamiento en el servidor en el cual se almacenen los datos con una estructura definida por la aplicación. 2. Crear una base de datos alterna únicamente para el tema de documentos digitalizados y desde la aplicación hacer la conexión a ambas bases para almacenar los documentos y/o la información referente a la aplicación. Aun estamos definiendo este tema, pero su apoyo y comentarios no han servido de mucho… Gracias. Saludos. > El 11/02/2016, a las 3:20 p.m., Alvaro Herrera > escribió: > > "Mario Jiménez Carrasco (isccarrasco)" escribió: > >> En la empresa donde laboro, tenemos actualmente una aplicación en la >> que se digitaliza documentos que son cargados directamente a la base >> de datos como objetos tipo batea, el primer cuestionamiento sería: >> ¿Es recomendable hacer esto?, o ¿Cuál sería el mecanismo mas recomendable? > > Hacerlo de esa forma funciona bien. Sobre todo, considera que si > pones los archivos fuera de la BD necesitarás considerarlas > separadamente en caso que quieras hacer respaldos y tener réplicas. > Si lo pones todo en la BD y manejas replicación streaming (o cualquier > otro tipo de replicación, en realidad), tus servidores réplica > automáticamente tendrán toda la información sin tener que preocuparte > de un mecanismo adicional para copiar los archivos. > > La BD será más pesada, obviamente, pero si no tienes el "peso" en la > BD entonces tendrás que tenerlo en otra parte, y no necesariamente > estarás en mejor pie. ¿O estás pensando en usar un sistema de > archivos en red, como LustreFS etc? > >> Por otro lado veo que el tamaño de la base de datos ha crecido (obvio >> por las imágenes), el cuestionamiento en este caso sería, ¿Existe >> algún plugin de PostgreSQL que comprima las imágenes sin perder la >> calidad? o ¿este un tema del lado de la aplicación?. > > Si el campo es grande, Postgres intenta aplicar compresión usando un > algoritmo relativamente rápido(*) pero no muy bueno. Si el formato es > PDF, JPEG o similar, que ya tienen compresión interna, es inútil que > la BD trate de comprimir de nuevo. En esos casos es mejor usar ALTER > TABLE SET STORAGE para que la columna se guarde sin intentar la compresión. > Si estás guardando texto ASCII o grandes documentos XML (que de por sí > son bastante compresibles), normalmente la compresión es buena idea; > si no, no. > > (*) en realidad, comparado con los nuevos algoritmos, no es tan rápido > tampoco :-( > > -- > Álvaro Herrerahttp://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci n: http://www.postgresql.org/mailpref/pgsql-es-ayuda - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
[pgsql-es-ayuda] [pgsql-es-ayuda] [OFFTOPIC] - Espacio en disco de tablas con imágenes.
Hola perdón por meterme en el hilo y mas teniendo en cuenta mi ignorancia, pero es posible que pudiera ser de utilidad para alguien. Respecto a dejar los datos dentro o fuera de la base, muchos me recomendaron hacerlo en un directorio aparte, pero jamas encontré un argumento que me convenciera ante las dificultades que ello conlleva. Todos los datos dentro de la base implica una enorme cantidad de ventajas que son las que originalmente nos hacen trabajar con base de datos relacionales (integridad, seguridad solo por nombrar algunos). Ahora yo al guardar datos graficos tengo algunas precauciones. 1) Validar todo lo que se pueda desde la aplicación. Por ejemplo el tamaño máximo que permito ingresar, tipo de dato, etc. 2) Armar otra tabla con el dato Bytea con únicamente este dato, incluso en una relación uno a uno. Esta tabla solo tendra el dato gráfico y el id de la tupla a la que corresponde. Esto para mi fue de mucha ayuda tanto en postgres mysql como en oracle. ya que me permite almacenar ese dato en otro datafile (segun el motor), tambien me protege de las consecuencias de que algun distraido hiciera "select * from tabla". Si pongo un trigger de auditoria o de lo que fuera el mismo puede trabajar sobre una de las tablas pero no sobre el dato gráfico. Las capas del medio de la aplicación (JPA) con muy poco esfuerzo levantan los datos que se requieren en cada caso y toman los graficos solo cuando son requeridos. Es muy posible que mi enfoque fuera anticuado pero a mi me da resultado. Les mando un fuerte abrazo. VHR
[pgsql-es-ayuda] Problema con consulta Postgis
Buenas tardes a todos Tengo una consulta que cada vez que es ejecuta directamente desde pgadmin funciona sin ningun problema esta es la consulta SELECT row_number() over(),ST_MakeLine(sp,ep) as the_geom FROM (SELECT ST_PointN(geom, generate_series(1, ST_NPoints(geom)-1)) as sp, ST_PointN(geom, generate_series(2, ST_NPoints(geom) )) as ep FROM (SELECT (ST_Dump(the_geom)).geom FROM rut_trazo v where vigente = 1 and trazo_id = 25 ) AS fa ) AS fo; Pero si lo ejecuto desde dentro de una función me da este error error:invalid join selectivity: 595447816.00,mensaje:XX000 la funcion que creo es la siguiente: CREATE OR REPLACE FUNCTION public.ruse50( valor integer, trazo integer) RETURNS text[] AS $BODY$ DECLARE -- num_currenti integer; retVal text[]; i integer; BEGIN create temp table taba as SELECT row_number() over(),ST_MakeLine(sp,ep) as the_geom FROM (SELECT ST_PointN(geom, generate_series(1, ST_NPoints(geom)-1)) as sp, ST_PointN(geom, generate_series(2, ST_NPoints(geom) )) as ep FROM (SELECT (ST_Dump(the_geom)).geom FROM rut_trazo v where vigente = $1 and trazo_id = $2 ) AS fa ) AS fo; retVal[0] := 'Se creo taba'; RETURN retVal; exception when others then retVal[0]:= 'error:'||SQLERRM||',mensaje:'||SQLSTATE; return retVal; END; $BODY$ LANGUAGE plpgsql VOLATILE COST 100; ALTER FUNCTION public.ruse50(integer, integer) OWNER TO postgres; He leido algunas consultas similares en los foros e indican volver a crear la tabla con create table rut_trazo_nuevo as select * from rut_trazo y luego trabjar con esa tabla pero el error periste lo extraño es que en algunas ocasiones funciona bien en otras arroja el error alguna pista -- José Mercedes Venegas Acevedo cel Mov RPM #955853768 mails: jvenegasp...@gmail.com
[pgsql-es-ayuda] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] [OFFTOPIC] - Espacio en disco de tablas con imágenes.
En efecto Mario… Las opiniones de la comunidad han enriquecido mas la visión… Estamos contemplando los dos escenarios que mencioné previamente, y analizando un poco el tema de discriminar desde la aplicación los tipos y tamaños de archivos que deben ser cargados a la base de datos… Hasta el momento nos está llamando mas la atención la segmentación de la base de datos, solo tendríamos que mover un schema de la base de datos hacia una nueva base de datos. Gracias por el apoyo…. Saludos. > El 12/02/2016, a las 11:47 a.m., Mario Soto Cordones > escribió: > > Hola > > Sin embargo, lo que indica Alvaro es un buen punto sobre todo si estás > realizando replicación, ya que no podrás replicar los documentos > digitalizados sino están almacenados en la base de datos. > En fin, creo que ya tienes más opciones para poder tomar una decisión. > > Saludos > > -Mensaje original- > De: pgsql-es-ayuda-ow...@postgresql.org > [mailto:pgsql-es-ayuda-ow...@postgresql.org] En nombre de "Mario Jiménez > Carrasco (isccarrasco)" > Enviado el: viernes, 12 de febrero de 2016 14:39 > Para: Alvaro Herrera > CC: pgsql-es-ayuda@postgresql.org > Asunto: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] [OFFTOPIC] - Espacio en disco > de tablas con imágenes. > > Buen día Alvaro… > > El punto que mencionas es precisamente lo que nos llevó a utilizar > inicialmente el mecanismo de cargar las imágenes y/o documentos a la base de > datos; la de poder tener toda la información disponible desde la misma base y > al moverse no tener que estar haciendo otras copias, sin embargo ahora nos > preocupa el tema de que la base de datos se ha vuelto muy pesada, y pensamos > que tal vez había formas más eficientes de manejar este detalle… > > Entre las propuestas que estamos analizando en el equipo son: > > 1. Manejar un directorio de almacenamiento en el servidor en el cual se > almacenen los datos con una estructura definida por la aplicación. > 2. Crear una base de datos alterna únicamente para el tema de documentos > digitalizados y desde la aplicación hacer la conexión a ambas bases para > almacenar los documentos y/o la información referente a la aplicación. > > Aun estamos definiendo este tema, pero su apoyo y comentarios no han servido > de mucho… > > Gracias. > > Saludos. > >> El 11/02/2016, a las 3:20 p.m., Alvaro Herrera >> escribió: >> >> "Mario Jiménez Carrasco (isccarrasco)" escribió: >> >>> En la empresa donde laboro, tenemos actualmente una aplicación en la >>> que se digitaliza documentos que son cargados directamente a la base >>> de datos como objetos tipo batea, el primer cuestionamiento sería: >>> ¿Es recomendable hacer esto?, o ¿Cuál sería el mecanismo mas recomendable? >> >> Hacerlo de esa forma funciona bien. Sobre todo, considera que si >> pones los archivos fuera de la BD necesitarás considerarlas >> separadamente en caso que quieras hacer respaldos y tener réplicas. >> Si lo pones todo en la BD y manejas replicación streaming (o cualquier >> otro tipo de replicación, en realidad), tus servidores réplica >> automáticamente tendrán toda la información sin tener que preocuparte >> de un mecanismo adicional para copiar los archivos. >> >> La BD será más pesada, obviamente, pero si no tienes el "peso" en la >> BD entonces tendrás que tenerlo en otra parte, y no necesariamente >> estarás en mejor pie. ¿O estás pensando en usar un sistema de >> archivos en red, como LustreFS etc? >> >>> Por otro lado veo que el tamaño de la base de datos ha crecido (obvio >>> por las imágenes), el cuestionamiento en este caso sería, ¿Existe >>> algún plugin de PostgreSQL que comprima las imágenes sin perder la >>> calidad? o ¿este un tema del lado de la aplicación?. >> >> Si el campo es grande, Postgres intenta aplicar compresión usando un >> algoritmo relativamente rápido(*) pero no muy bueno. Si el formato es >> PDF, JPEG o similar, que ya tienen compresión interna, es inútil que >> la BD trate de comprimir de nuevo. En esos casos es mejor usar ALTER >> TABLE SET STORAGE para que la columna se guarde sin intentar la compresión. >> Si estás guardando texto ASCII o grandes documentos XML (que de por sí >> son bastante compresibles), normalmente la compresión es buena idea; >> si no, no. >> >> (*) en realidad, comparado con los nuevos algoritmos, no es tan rápido >> tampoco :-( >> >> -- >> Álvaro Herrerahttp://www.2ndQuadrant.com/ >> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > > > - > Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) > Para cambiar tu suscripci n: > http://www.postgresql.org/mailpref/pgsql-es-ayuda > - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
