El 7/03/07, Alvaro Herrera <[EMAIL PROTECTED]> 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
