postgresql para almacenar documentos.

[Rodrigo Fuentealba]

El 7/03/07, Horst H. von Brand <vonbrand en inf.utfsm.cl> escribió:
> Rodrigo Fuentealba <darkprox en gmail.com> wrote:
> > Quiero implementar un software de administración de archivos al estilo
> > CVS/Subversion pero este es para planos en CAD, documentos de
> > OpenOffice (y Office, lamentable decirlo), y hartas cosas varias.
>
> Hum... alli no sirve de mucho lo de "control de versiones", andas
> buscando mas bien alguna clase de repositorio de documentos.

Se hace necesario guardar varios cambios del documento de acuerdo al
avance del proyecto (en etapa 1, este plano estaba así... en etapa 2,
así...).

> [... Ojo, esas cosas /tienen/ su propio sistema de control
>  de versiones integrado (por algo el archivo que solo dice "Nos vemos
>  man~ana" pesa 357KiB... tiene todos los mensajitos anteriormente
>  enviados empotrados en "versiones previas" para "undo") ...]

No es malo saber esto, pero como es algo "genérico" (no importa si
guarda fotos o no)... no podría hacer un software por cada tipo de
datos... termino el 11 de septiembre en la noche.

> > ...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,
>
> Te conviene pensar en algo como xdelta(1) (el algoritmo es la base de
> muchos de los esquemas de "manejo compacto" de diferencias entre
> archivos arbitrarios que usan los SCM de a deveras)

Checking (si no digo que el Google será provechoso!)

> Mi idea, a rasgos aun mayores, seria ver si alguno de los tantos
> sistemas de administracion de documentos hace algo como lo que quieres,
> y usar eso.

Estoy copiando la funcionalidad de un administrador de documentos
llamado Meridian, que hace lo que se requiere pero no como se requiere
(y eso que lo unico requerido es que lo haga bien; toda la empresa
cometió el error de adaptarse al software, cuando lo correcto es al
revés...), modificar alguna cosa en su behavior es un parto (podría
hacerse perfectamente a través de vistas de PostgreSQL... ya hice esa
parte) y es demasiado caro (US$ 50.000, si utilizamos la base de datos
integrada de AM-Meridian... US$ 50.000 + la licencia de SQL Server
2000, que se rehusa a usar SQL Server 2005 o MSDE si queremos otras
cosillas más).

> Si, no sera 100% lo que buscas/quieres, pero te costara a lo
> mas un 5% de lo que es desarrollar el cuento por ti mismo

De hecho, es más barato desarrollar el cuento por mí mismo y poder
ofrecer la solución a otras empresas.

> lo tendras en
> funciones en 0,5% del tiempo, y el costo de mantencion se reduce a un 1%
> de lo que significa hacerlo todo tu (suponiendo que elegiste bien, y es
> un proyecto activo).

Eso sí.

> Y olvidate de "interfases hacia el lenguaje X du jour", mete todo el
> cuento tras /una/ interfaz web, programada en lo que este de moda hoy.

Uhmmm.

> > [ oid v/s bytea ] ¿cuál será mejor, y por qué? sé cómo manipular ambos
> > tipos de datos, pero desconozco los detalles de las diferencias como
> > para discriminar, ¿qué me aconsejarían ustedes?
>
> Usar la base de datos para simplemente guardar el nombre del archivo en
> un repositorio ad hoc no es mas simple?

Puede serlo, pero habrá referencias sin archivos y archivos sin
referencias. Quería aprovechar la integridad referenciada de las bases
de datos, para tener un control más fino por departamento, por perfil
de usuario, por especialidad, etc...

> (Si, ocupa mas espacio; pero has
> preguntado ultimamente cuanto cuesta un disco de taman~o decente?).

Si... ocupa espacio.

>  y obtener
> la "ultima version" (la unica que normalmente interesa) es mucho mas
> eficiente (por algo ya el venerable RCS guardaba no diferencias desde el
> comienzo incrementalmente hasta el final, sino la ultima version y
> diferencias hacia atras).

Interesante detalle.

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