2009-11-18 8 views
2

Comme je vois LIKE opérateur peut optimiser requête si je commute PRAGMA case_sensitive_like = ON. J'ai mesuré, ça a vraiment marché, les requêtes "LIKE someth%" deviennent dix fois plus rapides sur des tables indexées binaires relativement grandes. Mais le problème est que ma bibliothèque implémentée comme un add-on à mon application, elle maintient ses propres tables avec n'importe quel DB il est connecté. Les problèmes sont doncFaçon commode d'utiliser la sensitivité de cas LIKE en sqlite

  • Je ne peux pas lire case_sensitive_like car il est pris en charge à régler, pas lire. Donc, je ne peux pas lire temporairement l'état et le retourner après la requête,
  • Comme un addon qui devrait obéir à la fonctionnalité principale de la DB, je ne devrais pas changer le paramètre à mon besoin de bien, car il peut affecter d'autres routines.
  • Comme je vois il n'y a aucun équivalent interne Like (sensible à la casse) pour que j'appelle la requête optimizid directement. Par exemple utiliser LIKECASESENSITIVE au lieu de LIKE
  • Je peux appeler sqlite3_create_function, mais je ne sais pas si je peux appeler LIKE (CASE SENSITIVE) en interne.

Répondre

6

Je ne peux pas lire case_sensitive_like car il est pris en charge à régler, pas lu. Je ne peux pas temporairement lire l'état et le retourner après la requête

Vous pouvez obtenir l'état de case_sensitive_like avec une requête comme celle-ci:

select case when 'a' like 'A' then 0 else 1 end 

qui retournera 1 si case_sensitive_like = ON et 0 si c'est OFF.