Busqueda en backups DVD

[Rodrigo Fuentealba]

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