|
Buscador de Documentos
Hola:
Bueno, esta vez pregunto si alguien me puede orientar en como iniciar un buscador de documentos dentro de una red de computadoras, algo al estilo de google. Es decir, hacer una buscador que ponga por ejemplo "club delphi" y este me traiga todos los .doc o fotos o pdf o pps que halla dentro de una red, y haciendo un clik me lo habra. Y no tengo ni idea de como hacerlo. Gracias Luis Roldan Mar del Plata |
Creo que pides mucho chaja.
Lo primero que tienes que hacer es indexar los documentos. Luego, tienes que elegir un algorítmo de búsqueda en los índices. El resto, en comparación a lo anterior, es pan comido. Saludos, Chris |
Yo diría aun más...
* Lo primero que debes diseñar es la estructura de la Base de Datos. Tal como dice Chris, debes indexar todos los documentos. * Por un lado debes diseñar el indexador. Programa que deberá correr en todas las máquinas y que debe ir actualizando en contenido de los índices en la Base de Datos con lo que vaya cambiando en cada máquina (nuevos docs, documentos que se borran, que se mueven,...) * Y por último el buscador (que creo que es el más sencillo) que lo único que hace es buscar en Base de Datos y Abrir el documento. Debes tener en cuenta qué datos vas a guardar, cómo indexar y el tema de permisos a la hora de abrir documentos. OTROS: ¿Vas a indexar contenidos? Si es así. ¿El usuario que abre puede modificar o abre una copia? ... la cosa por aquí se complica. |
Aunque puesto a hacerlo en plan "chapuza total", simple y rápido, hay otra opción :D
En cada equipo haces un: dir c:\*.* /s > disco_c_ordenador_A.txt Si tiene más de un disco entonces lo haces por cada disco dir d:\*.* /s > disco_d_ordenador_A.txt Así con cada ordenador: dir c:\*.* /s > disco_c_ordenador_B.txt etc. Esos ficheros creados con la estructura de todos lo que hay en cada disco de cada equipo lo pones en un lugar compartido o lo copias a un lugar común. También puedos unir todos ellos en uno sólo. Luego sólo tienes que hacer una simple búsqueda porque está en formato texto. Todo depende de la necesidad que tengas por cubrir, el tiempo, los recursos disponibles, lo que quieras realmente conseguir, etc. en este caso es sólo para saber dónde está un fichero en particular, luego tendrías que ir a ese equipo para verlo. |
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 |
Cita:
El problema es que antes de empezar debes tener claro (para la estructura) qué es lo que necesitas. Cita:
¿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. Cita:
Cita:
|
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. |
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.
|
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... |
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. |
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... :( |
Cita:
|
Cita:
Hace pocos años rebajé un presupuesto cerca de 8 mil dólares, con lo cual el cliente terminó por decidirse y aceptó mi propuesta en lugar de contratar a SAP. Gané esa estúpida batalla contra el gigante alemán, pero al cabo de dos años terminó siendo SAP el que se quedó con ese cliente y yo debiéndole unos 30 mil dólares a éste, deuda con la cual amanezco día tras día desde hace tres años. |
Cita:
También aprendí de los errores :) |
bien...
los datos de mamcx, no los tenia, la verdad que esta bueno eso.... ayer me reuni con una persona allegada a la intersada, y mas o menos la oriente con lo que me paso mamcx. No se, debo hablar ahora con la intersada. El tema es que tiene mas de 30 giga de documentos y se le complica entre buscar y ademas de clasificar. Se dedica a ciencias politicas, asi que la cantidad de doc. y pp es muy grande. Incialmente si hago el prpyecto sin usar las opciones que dio mamcx, es hacer una tabla e indexar los tiutlos? que les parace. COn refe. a los presupuesto , Al , lo tuyo me parece loable, por lo menos haber ganado enfrentarte con el aleman, pero que tiene sap de bueno que nostros no tenemos? nunca vi un sistema SAP. bien, si se les ocurre algo mas bienvenido sea..... gracias Luis Roldan Mar del Plata Argentina |
Cita:
Lo primero es complicado y resultará caro. Lo segundo es facilísimo, incluso puedes usar programas como whereisit portable (supongo que será windows) y no tendrías que invertir nada. |
Concuerdo.
Me gusta mucho el concepto del zen de python: Simple es mejor que complejo. Es normal que en la cabeza las personas relacionen lo que creen que necesitan con lo que otros usan. De ahi a pensar: " Quiero un buscador como Google "... pero eso implica o el nivel de conocimiento o los recursos que han invertido - guardando las proporciones -. Nuestro proposito es encontrar un equilibrio entre lo que se puede y lo que se quiere. Y una mejor opción o solución al problema que se nos pide afrontar. Una buena idea, es que en una pizarra, papel o lo que sea, trates de visualizar como funcionaria el juguete una vez listo, hacer muchas preguntas para sacarle al cliente lo que espera (la gente no sabe lo que quiere, pero si lo que espera!), y luego encuentra la vis mas simple para resolverlo. Un mero indexador de nombres de archivos con una escucha que detecte cuando se cambio, quita o agrega a un directorio, se puede hacer en un par de dias (ya hay componentes para todo eso... es muy facil). Tambien, puedes usar el codigo de launchy o similar. Ya funciona y es muy bueno (es el que uso en windows). |
| La franja horaria es GMT +2. Ahora son las 18:12:44. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi