busquedas lentas una subcadena en campo memo sqlite

[mamcx]

Empezado por Casimiro Notevi

De todas formas, ¡¡¡ a quién se le ocurre usar una BD de juguete para estas cosas !!!

Juguete? Sqlite es una BD muy capaz, para sus casos de uso.

Aunque es cierto que FB por ser una BD servidora tiene mas funcionalidad, el problema que se expone realmente como lo va a ser mejor?

En *CUALQUIER* motor de BD es el mismo y exacto problema. Esto es un caso patologico para cualquier BD relacional:

1- Hay muchos registros
2- Es Texto
3- Lo que se busca esta en cualquier parte del campo
4- No hay indice

Por lo tanto, hay un TABLE SCAN forzado. Y es mas, apuesto (aun sin hacer pruebas) que SQLITE es mas rapido que cualquier otro motor *precisamente* porque es una BD local y no una servidor que tiene que hacer todo por protocolos de red remotos.

Ademas, el usar un indice aqui dificilmente va a servir de NADA:

http://stackoverflow.com/questions/9...ebird-database
http://web.utk.edu/~jplyon/sqlite/SQ...ation_FAQ.html

FB & Sqlite (Y no veo que BD sea capaz) tienen el mismo problema al hacer busquedas donde el texto a encontrar estan en cuaquier parte, y solo (posiblemente) pueden usar indice si el LIKE es asi: 'Prefijo%', pero falla si es asi: '%Sufjio' o peor '%QuienSabe%'.

Asi que hacer un cambio de codigo/bd/tecnologia por esto solo no servira de mucho.

Cual es la solucion?

Una idea se da en:
http://web.utk.edu/~jplyon/sqlite/SQ...ation_FAQ.html

Código SQL [-]
If a * or % wildcard occurs in the middle of a string, or a complex pattern appears at the end, we can still use the above techniques to create a filter test which is done before the more expensive pattern test.
Example: The expression (x GLOB 'abc*jkl*') can be replaced by (x > 'abc' AND x < 'abd' AND x GLOB 'abc*jkl*').
Example: The expression (x LIKE 'abc_') can be replaced by (x > 'abc' AND x < 'abd' AND length(x) == 4)

La otra, mas simple es usar Full Text Search (un punto extra por Sqlite: FB no tiene una solucion FTS INTEGRADA):

https://www.sqlite.org/fts3.html

Con esto, las busquedas se resuelven en milisegundos, con el trade-off de que la BD crecera un poco mas por el uso de FTS.

El asunto es que como dice la teoria, uno escoje optimizar TAMAÑO o optimizar TIEMPO y no se puede ambas, asi que aparte de hacer malabares con los querys, usar FTS o encontrar una forma de almacenar el texto emulando una estructura de datos (ej: Cada palabra se guarda en una tabla separada con relacion a la tabla donde esta el texto "grande", o se usa algo similar a un ROPE (https://en.wikipedia.org/wiki/Rope_(data_structure)) u otra cosa) no hay vuelta con esto.