postgresql para almacenar documentos.

[Rodrigo Fuentealba]

El 7/03/07, Alvaro Herrera <alvherre en alvh.no-ip.org> escribió:
> Rodrigo Fuentealba escribió:
>
> > Ahora, para esto tengo dos posibilidades: OID's y byte arrays.
>
> Yo te recomendaria usar bytea.
>
> Los "large objects" (LO) tienen la desventaja de que no tienen control
> de acceso y tienen una API que es totalmente diferente de lo que uno
> acostumbra a usar en SQL (lo_open, lo_read etc).  Cuando quieres hacer
> alguna cosa en "relacional" quedas muy amarrado de manos.

Ya me ha pasado con oids

> Por otro lado, en Postgres el uso de bytea esta bastante optimizado por
> el mecanismo conocido como TOAST.  Te recomiendo usar
> ALTER TABLE tabla ALTER COLUMN columna SET STORAGE EXTERNAL
> en la columna bytea, de manera que el sistema no trate de comprimir los
> datos almacenados (generalmente la compresibilidad de esos documentos no
> es mucha, y es mas rapido el acceso si no tiene que estar
> comprimiendo/descomprimiendo).

Dato interesante.

> (*) la alternativa a escapar/des-escapar es usar una API como
> PQexecParams, pero si vas a usar PHP creo que eso no esta disponible.
> En lenguajes razonables puedes hacerlo y es mucho mas eficiente porque
> los datos binarios pasan directo a la base de datos y no se tiene que
> gastar memoria en el proceso de escape.

(-_-) si... me rindo con php...

> Con respecto a la alternativa de almancenar los datos en el sistema de
> archivos y guardar solo una referencia en la BD, te recomiendo que no lo
> hagas a menos que el volumen de datos sea muy grande (hablo de decenas
> de GB).  Es muy dificil hacerlo correctamente, sobre todo si nunca lo
> has hecho, y no hacerlo correctamente lleva a documentos sin referencia
> y referencias a documentos inexistentes, que son muy incomodos de
> manejar.

<!-- lo siguiente llegó en otro correo de Alvaro -->

>> de tal manera que yo pueda hacer una suerte de
>> "diff" para archivos binarios y guardar el archivo una sola vez y
>> luego poder ir viendo progresivamente los cambios,

> Lo que estas proponiendo es un mecanismo muy fragil e
> ineficiente.  Almacenarlo todo tiene un costo mayor en espacio de
> almacenamiento, pero es mucho mas simple de manejar en codigo y mas
> resistente a fallas.

Muchas gracias Alvaro.

La solución que se planteó fue precisamente para intentar ahorrar
"algo" de espacio en disco y emular el comportamiento de otra
aplicación como esta, que guarda sus datos en disco y ha funcionado
como... bueno, mal.

No había visto esa cara de la moneda.

-- 
Rodrigo Fuentealba Cartes
Desarrollador de Sistemas Web
Registered User 387639 - http://counter.li.org