Buscador de Documentos

[Chaja]

haber si entiendo....
deberia hacer en una BD , por ejemplo interbase una tabla con los documentos , del formato
Id :integer
Nombre_archivo :varchar(100)
path_ubicacion:varchar(100)

despues hacer un findfile() y buscar los doc.pdf.bmp. xls e ir incorporandolos a la base de datos, pero en el caso de los doc, puedo indexar contenido?
esto doc lo deberia abrir desde mi propia aplicacion?, pues si el user hace alguna modif. o lo borra... deberia reindexar todo de nuevo, va ser un proceso lento no?

mmmmm no se....

Luis

[Neftali [Germán.Estévez]]

Empezado por Chaja

deberia hacer en una BD , por ejemplo interbase una tabla con los documentos , del formato

Yo creo que esto es casi obligatorio.
El problema es que antes de empezar debes tener claro (para la estructura) qué es lo que necesitas.

Empezado por Chaja

despues hacer un findfile() y buscar los doc.pdf.bmp. xls e ir incorporandolos a la base de datos, pero en el caso de los doc, puedo indexar contenido?

Vayamos con la premisa de que TODO se puede hacer, lo que pasa que cuantas más cosas quieras hacer más complejo es.
¿Se puede indexar por contenido? SÍ, pero es más complejo.

Puedes dejarlo para una 2ª versión, no lo implementes todavía, pero tenlo en cuenta en los diseños para luego. Puedes empezar primero implementando sólo la indexación por nombre.

La indexación lleva 2 pasos.
(1) Una indexación "inicial" que lo que hace es buscar TODOS los documentos que hay y los añade a la base de Datos (esto se hace en todos los equipos). Este proceso es largo y costoso y normalmente se hace como primer paso una vez instalada la aplicación (2º plano y con cuidado de no consumir muchos recursos).
(2) Luego debes tener un proceso en segundo plano que vaya "actualizando" la información a medida que el usuario crear/borra/renombra ficheros en el equipo. (***)

El tema de indexar contenido es aparte y si te interesa podemos discutirlo más adelante para no liar más.

Empezado por Chaja

esto doc lo deberia abrir desde mi propia aplicacion?,

Con esto no se a qué te refieres.

Empezado por Chaja

pues si el user hace alguna modif. o lo borra... deberia reindexar todo de nuevo, va ser un proceso lento no?

TODO no!!! Sólo los documentos que se crean nuevos, que se modifican o que se borran. Por eso debes tener un proceso en 2º plano (***) que va "vigilando" esas modificaciones y actualiza la Base de Datos.

[mamcx]

Ese es un proyecto que lo he soñado de hace tiempo, y llegue a iniciarlo varias veces.

Con pena debo decir que cuando MS presento lo que se suponía seria Vista con su nuevo sistema de archivos, me asuste y pense que perderia el tiempo siguiendo el desarrollo... como me ha pesado haberlo hecho...

Con la experiencia previa, y los conocimientos actuales, te puedo decir:

1- Este es un proyecto COMPLEJO. Bastante. Es fregao fregao.
2- Debes leer sobre que es un Document management system

Los MAS populares y la competencia inmediata son http://www.alfresco.com/es/ (open source) y por sobre todo http://sharepoint.microsoft.com/es-e...s/default.aspx

Puedes desarrollar sobre ambos, en vez de hacerlo desde cero. Luego de pensarlo mucho, a mi no me gusta. No me gust ninguno de los que hay en el mercado, pero es cosa tuya en base a lo que quieres hacer, asi que olvida lo que te dije

3- Es un ERROR ERROR ENORME usar una BD relacional. MALO DE LO MALO.

Las BD relacionales estan optimizadas para registros y columnas, no archivos sin estructura.

Tu mejor opcion al dia de hoy es http://www.mongodb.org/ y http://www.couchbase.com/.

No puedo recalcar este punto mas. Es un aspecto critico que afectara todo. EL porque? Bueno, debes leer mucho, o creerle a yahoo, google y demas que no usan BD relacionales para sus buscadores.

4- Necesitas un motor de busqueda. Aqui hay malas noticias. Esta es la parte fregada fregada de todo esto, porque significa que necesitas 2 sistemas corriendo en paralelo: La Bd documental y el motor de busqueda. Es mejor si estuviera en un solo paquete, pero no conozco tal bestia.

Te puede tentar usar los modulos integrados que vienen en postgress o sql server, pero al facilitarte por ese lado perderas por usar una relacional.

La opcion mas inmediata es http://lucene.apache.org/java/docs/index.html.

Puedes emular un buscador e integrarlo DENTRO de la BD no relacional. Es algo que se ha hecho y funciona bien... PERO debes saber como hacerlo, y eso no es facil.

Esta es la parte fregada fregada. El buscador es la interface principal del sistema de cara al usuario. Como lo enfrentes determinara el exito o no del sistema.

La mejor opcion, digo yo, es tirar muy bajo y anular el concepto de buscador tipo google. Si tienes un mac, analiza como funciona http://en.wikipedia.org/wiki/Spotlight_(software). Sino, instala y mira como funciona http://www.launchy.net/ (aqui tenes codigo).

Me parece que es la opcion mas simple, y que funciona razonablemente bien.

5- Almacenamiento en serio

Preparate para entender lo que significa almacenar los datos de todos los archivos en un red. Estamos hablando de GB, y muy rapido, de TB (a menos que sea solo un subconjunto de archivos y red muy chica).

Aqui es donde empieza el error grave de usar relacional. Se vuelve costoso, pronto y rapido.

Cuan costoso?

Preguntemosle a unos expertos:

http://www.slideshare.net/alfresco/w...o-presentation

Solo software para 100 usuarios

Alfresco: US 19.000
Sharepoint: US 25.000

Se necesitan ademas unos 2-3 servidores, con capacidad de almacenamiento que aguante los TB, y todo lo que eso implica. Una vez que hice el calculo, creo que me dio mas de US 10.000 para algo elemental (usando alfresco, 100 usuarios). Puede que sea hoy diferente.

Un aspecto que hace costoso la operacion de estos 2 sistemas, es que usan relacional. Con un NoSql se baja mas de la mitad.

6- Jalar el contenido de los archivos (tipo office y otros)

Esto es muy posible, de hecho lo hice hace unos años y funcionaba relativamente bien, tanto que temine por darle parte del codigo a http://www.scalabium.com/sme/.

Pero solo sale facil en windows. En linux ni hablar de lo complicado que es. No se que tanto en OSX.

7- Un error hacerlo solo, sin experiencia ni recursos

Esto fue lo que me mato. Estaba solo, exige averiguar sobre muchas cosas, meterse con APIs, y sin recursos? Te mueres pronto.

Pense en su momento hacerlo open source, pero aqui en latinoamerica eso no funciona...

Si no tienes quien te subsidie el desarrollo, diria que hacerlo por amor al arte sera dificil, a menos que lo montes sobre sharepoint o alfresco, lo cual es como bobada, porque ya hay empresas que dan mejor ese paquete.

[Casimiro Notevi]

Creo que Chaja debe decidir si almacenar sólo nombres para buscarlos o contenidos de los mismos, la diferencia es abismal entre uno y otro método.

[mamcx]

Obviamente... pero sin el contenido la busqueda se hace dificil.

Un aspecto que olvide mencionar es que en estos sistemas es tipico guardar el archivo *dentro* del mismo sistema. Esa es la manera de sharepoint y alfresco, asi que es un supuesto que maneje en la respuesta...

[Casimiro Notevi]

Es que las bases de datos documentales han sido siempre un tema muy "duro de roer".
Un buen sistema de ese tipo tiene el éxito asegurado.

[mamcx]

De acuerdo.

El problema es que es dificil encontrar el cliente que este dispuesto a invertir en su desarrollo. Y tambien el problema de que se supone que eso solo lo saben hacer los grandes.

A una de las grandes empresas del pais me pidio un proyecto de estos (que almacenara ademas los archivos de forma segura hasta por 20 años) y termino comprandoselo a Oracle por mas de 1.000 millones de pesos de diferencia.

Simplemente, era demasiado pequeño y no me creyeron...