Busqueda en backups DVD

[Marco González Luengo]

El día 28 de julio de 2008 0:11, Rodrigo Fuentealba
<the.code.keeper en gmail.com> escribió:
> El día 28 de julio de 2008 5:43, Aldrin Martoq <amartoq en dcc.uchile.cl> escribió:
>>
>> Bueno, asincronismo javascript dhtml y todas esas cosas que el buzzword
>> resume en AJAX. Estoy seguro que se puede hacer algo como lo que pido,
>> multiplataforma (asincronismo javascript dhtml etc) y localmente. La
>> parte XML la quiero obviar! ;)
>
> Ok.
>
>> Aqui una prueba, que estoy estudiando como usar:
>> http://www.ecosmear.com/relay/
>>
>> Parece que lo top en esto es Prototype y Script.aculo.us.
>
> Asi es.
>
>>> 2.- Tener un índice de los archivos implicaría (ambas):
>>> 2.a.- Que tengas algo así como PostgreSQL embebido usando TSearch2
>>> 2.b.- Que tu backup sea de 2Gb + 2Gb de datos de la PostgreSQL + el resto.
>>
>>> 3.- En el mejor de los casos, a medida que vas agregando archivos al
>>> respaldo, puedes ir generando un índice y antes de "Burn" agregar
>>> también este archivo;
>>> algo ilógico y difícil.
>>
>> Es un indice de "palabras", no tienes que hacer scan del contenido.
>
> Entiendo ese indice como lo que hace TSearch2 para optimizar el tiempo
> de las búsquedas de textos. Quizás puedes usar un modelo simplísimo
> como (lo escribiré en SQL, pero lógicamente es trivial de hacer hasta
> con CSV):
>
> CREATE TABLE archivo
> (
>    id integer,
>    archivo longvarchar
> );
>
> CREATE TABLE palabra
> (
>    id integer,
>    palabra varchar
> );
>
> CREATE TABLE palabraarchivo
> (
>    palabra_id integer,
>    archivo_id integer,
>    foreign key (palabra_id) references palabra (id),
>    foreign key (archivo_id) references archivo (id)
> );
>
>> Basicamente una lista de palabras y cada palabra tiene una lista de
>> archivos que contienen dicha palabra.
>
> Mejor una lista de archivos, una de palabras y una relación entre
> ambas... no hay redundancia de esta manera ;-).
>
>> Luego ante una busqueda haces un
>> scan sobre la lista de palabras y tienes todos los archivos. Es muy
>> eficiente, ya tengo una aplicacion pygtk que lo esta haciendo bastante
>> bien y rapido sobre 70.000 archivos, por ahora solo con los nombres de
>> archivo
>
> ¿Cómo lo haces para identificar los archivos que debe escanear y los
> que no? Por ejemplo, los binarios deben contener strings dentro de
> ellos, pero no me interesa leer esos archivos.
>
>> falta programar que agregue mas palabras al indice escanenado
>> el contenido de los documentos, pero ya con lo que tengo es bastante.
>>
>> No necesitas base de datos ni nada muy complejo, la busqueda no es tan
>> extensa y de todas formas hay que hacer un scan de todas las palabras
>> (recorrer todas las filas). A menos que busques de otra forma (similitud
>> de palabras por ejemplo?)
>
> SOUNDEX, LIKE; estaba pensando en eso.
>
>> Tampoco tienes el problema de las actualizaciones del indice, pues lo
>> regeneras de nuevo; el indice no se actualizara en un DVD o respaldo.
>
> Un archivo de base de datos SQLite, o en el peor de los casos, tres
> archivos DBase. Si incluyes un binario estático de una aplicación que
> los lea, podrías usarlo en varios Linux (y en MacOS, quizás?). Y es
> trivial hacer algo para Windows (ya que es la única plataforma que no
> asegura que tus programas corran ahí) con eso.
>
>>> Siempre puedes cocinar algo con find, grep, sed, awk, xargs, locate;
>>> en una de esas te conviene hacerte utilidades que busquen en el disco
>>> entero y agregar esas utilidades a cada uno de los backups.
>>
>> Ya he hecho eso, y a mi no me funciona... De hecho, no encuentro el
>> ultimo catalogo que hice de esta forma (a punta de find's y rotulado de
>> discos a manopla)
>
> :s
>
> Por eso prefiero usar nombres descriptivos en mis archivos.
>
> --
> Rodrigo Fuentealba
> Concepción, Chile
>
>

Fuera del dilema técnico que está en discusión actualmente, y que
encuentra bastante interesante, me han surgido alguna preguntas que...
bueno, cualquier end user se hace.

- ¿Qué clase de catálogo quieres buscas hacer? ¿De cada Disco o de una
serie de respaldos (respaldo-pt1, respaldo-pt2, etc)?
- ¿El ejecutable viene en el disco?
- ¿Existirá esto para end users en algún futuro próximo?

Y aparte de eso, estaba pensando en qué tan dificultoso sería que
trabajaras eso con una base SQLite, tal como hace Firefox actualmente
(aunque consumiendo menos RAM). A lo mejor por ahí va la cosa...

Saludos, y éxito con tu trabajo. :D