SQLite, like i znaki narodowe
Zadałem tu jedno pytanie i spotkało się to ze sporym odzewem, więc rzucę taki inny temat, może pominąłem jakiś aspekt i dlatego był to dla mnie problem, a może też komuś to pomoże.
Otóż korzystam z bazy danych do przechowywania danych o finansach. Czymś normalnym jest tam możliwość wprowadzenia opisu transakcji, płatnika/odbiorcy transakcji, a także kategorie mają własne nazwy. Z uwagi na ukierunkowanie Androida na wyszukiwanie danych (jest nawet wymagany fizyczny przycisk odpalający wyszukiwanie) także zaimplementowałem sobie mechanizm wyszukiwania przy pomocy SearchManager (pojawia się od góry standardowy popup z ikonką, możliwością wpisania co chcemy szukać - po prostu standard).
Nie szuka się tu dokładnie po opisie, tylko jak to z reguły bywa po części tekstu (prawie jak Google), ja sobie ustaliłem, że może to być zawartość wyżej wymienionych pól. Oczywiście całość działa poprzez zwykłe, standardowe LIKE w SQLu. I tu zaczynają się schody, SQLite niepoprawnie interpretuje LIKE zawierający polskie znaki. Tzn. po prostu nie znajdzie nigdy rekordu który pasuje, jednak w szukanym tekście jest polska litera. Miał ktoś podobny problem?
PS. Ja to rozwiązałem dzieląc wyszukiwanie na dwa etapy, pierwszy uogólniam wyszukiwany ciąg pozbywając się polskich znaków, drugi przed akceptacją rekordu ponownie go weryfikuje i sprawdzam, czy nie należy go czasem pominąć.
PS2. Raczej odpadają rozwiązania oparte o FTS3 i FTS4, bo wymuszałyby konieczność przygotowania tabel w tym formacie z zawartością wszystkich pól po których szukamy przed samym wyszukiwaniem. Tak więc ewentualne korzyści (np. czas wyszukiwania) były znikome, a nie wiem nawet czy nie napotkałbym tego samego problemu tutaj.
Zrób sobie dodatkową kolumnę do wyszukiwania, bez polskich znaków. Rozwiązanie nie jest eleganckie, idealne itp. ale najszybsze chyba.
Na jakieś rozszerzenia SQLite bym za bardzo nie liczył - próbowałem kiedyś uruchomić na androidzie jakąś tabelę wirtualną i był spory problem (chodziło o rindex) - implementacja SQLite na telefonie nie jest aż tak pewna, jak Google twierdzi.
To rozwiązanie odrzuciłem na starcie. Za dużo pól, za dużo danych byłoby powielonych, a przecież rozmiar bazy też jest istotny. Wirtualne tabele także wykorzystuje bez większych problemów (przynajmniej jak na razie w zakresie jaki potrzebuję), jednak to, że implementacja SQLite zawarta w Androidzie troszkę odstaje to już zdążyłem zauważyćZamieszczone przez piotrpo
. Poza tym sam SQLite jest jak dla mnie sporą... powiedzmy jest ułomny (z reguły pracuję na bazach Oracle i Firebird).
Akurat w porównaniu do Oracle, to każda baza danych jest lepsza
Tak mi przyszło do głowy - nie wrzucałeś tych danych jakoś "inaczej" że nie chce ci wyszukiwać?
biorąc pod uwagę twoje niezwykle wygórowane wymazania pozostaje jedynie Full-Text czyli wspomniany już FTS3, można jeszcze zamienić polskie znaki na coś unikalnego i zjadliwego dla mechanizmu wyszukiwania ale tu zawsze występuje rozrost informacji a chcesz mieć możliwie mała bazę nie wspominając o startach w czasie choć nie sądzę żeby to był problem w twoim przypadku
PS. właśnie zrobiłem eksperyment dziwne ale wcześniej nie zastanawiałem się na tym wydało się to oczywiste, mechanizm wyszukiwania prawidłowo radzi sobie z lokalizowanymi znakami. sprawdź czy czegoś nie pokręciłeś albo daj sobie spokój z usługą i zrób własny CursorAdapter z AutoCompleteTextView
Ostatnio edytowane przez zawadaki ; 10-04-11 o 13:08
Trudno stwierdzić "inaczej". Problem w tym, że LIKE musi być case insensitive i tak też jest w SQLite, jednak z wyłączeniem znaków narodowych. Nawet UPPER działa niepoprawnie, bo nie potrafi np. z ó zrobić Ó. Pewnie cały problem leży właśnie w obsłudze znaków narodowych jeśli chodzi o rozmiar znaków.Akurat w porównaniu do Oracle, to każda baza danych jest lepsza
Tak mi przyszło do głowy - nie wrzucałeś tych danych jakoś "inaczej" że nie chce ci wyszukiwać?
Jasne, można i problem błahy, pomijalny, ale trochę głupio zrobić mechanizm w którym wpisując słowo "śliwka", program nie znajdzie pozycji nazwanej "Śliwka"
Czyli zakładasz, że w FTS3 byłby taki sam problem? No to już całkiem porażka, to całkiem dyskwalifikuje FTS3. Bo o ile jest uzasadnione wykorzystanie tego mechanizmu w aplikacji która opiera się na wyszukiwaniu (nie wiem, np. jakiś słownik), to w zwykłej aplikacji w której po prostu chce mieć możliwość szukania mija się to z celem.
A co do zamiany polskich znaków, w tym rozwiązaniu przecież i tak będzie trzeba na końcu zrobić selekcję wyniku podobnie jak ja to rozwiązałem. Czyli jednak SQLite jest tu kulawy i nic się nie da zrobić
---------- Post dołączono o 14:13 ---------- Poprzedni post napisano o 14:12 ----------
To sprawdź jak to opisałem wyżej, tj. wpisz do pola Śliwka i wyszukaj ten rekord wpisując śliwka
to nie jest problem z Androidową baza ale ogólnie z SQlite żeby to rozwiązać użyj właśnie FTS3 bo z LIKE to nie wyjdzie
---------- Post dołączono o 14:13 ---------- Poprzedni post napisano o 14:12 ----------
[/COLOR]To sprawdź jak to opisałem wyżej, tj. wpisz do pola Śliwka i wyszukaj ten rekord wpisując śliwka
Pewnie tak, bo to samo mam na desktopie. To mój pierwszy kontakt z SQLitem i szczerze dobijające to jest. Np. do pól zmiennoprzecinkowych też mam sporo zastrzeżeń i po prostu ich nie stosuję. Ale to inna bajka, w każdym razie faktem jest, że SQLite jest prostą bazą do prostych zastosowań, jednak chcąc wykorzystać Androida bardziej poważnie jesteśmy skazania na SQLita.
Co do FTS3, to powiem tak, plik bazy około 500kB, praktycznie każda tabela ma pole tekstowe po którym bym chciał szukać, co daje mi bardzo duży narzut do samego przygotowania bazy do jednego, prostego wyszukiwania. Gra nie warta świeczki, wolę swój patent który działa
To pisz, że problem masz z upper, a nie z like - przecież operator z natury jest case sensitive. Pytałem o to, czy dane w bazie masz załadowane z UI aplikacji, czy też poprzez jakiś import twoich starych danych - mogą pojawić się problemy w takim przypadku.
Coś mi się kojarzy, że SQLite ma możliwość dopisywania własnych funkcji - może wystarczy napisać własne lower() ?
Teoretycznie w bazie masz UTF-8, więc problemów z polskimi znaczkami nie powinno być.
Powinno, nie powinno, ale jest jakaś kulawa implementacja UTFa. Co do UPPERa, z nim nie mam problemu, bo go najzwyczajniej nie używam
PS. Dane mam w większości zaimportowane, jednak to akurat nie ma większego znaczenia.
Odpowiedz z cytatem
