5 måder at implementere case-usensitiv søgning i SQLite med fuld Unicode-understøttelse

Returner en casefoldet kopi af strengen. Casefoldede strenge kan bruges til kasseløs matchning.

Casefolding ligner små bogstaver, men mere aggressiv, fordi den er beregnet til at fjerne alle case-forskelle i en streng. For eksempel svarer det tyske lille bogstav 'ß' til "ss". Da det allerede er små bogstaver, lower() ville ikke gøre noget ved 'ß'; casefold() konverterer det til "ss".

Derfor vil vi nedenfor bruge str.casefold() funktion for alle konverteringer og sammenligninger.

2. Applikationsdefineret sortering

For at udføre en søgning uden store og små bogstaver efter alle Unicode-symboler skal vi definere en ny sortering i applikationen efter at have oprettet forbindelse til databasen (dokumentation). Her har du et valg – overbelast den indbyggede NOCASE eller lav din egen – vi vil diskutere fordele og ulemper nedenfor. For et eksempel vil vi bruge et nyt navn:

import sqlite3

# Custom collation, maybe it is more efficient
# to store strings
def unicode_nocase_collation(a: str, b: str):
    if a.casefold() == b.casefold():
        return 0
    if a.casefold() < b.casefold():
        return -1
    return 1

connection.create_collation(
    "UNICODE_NOCASE", unicode_nocase_collation
)

# Connect to the DB and register the function
connection = sqlite3.connect("your_db_path")
connection.create_collation(
    "UNICODE_NOCASE", unicode_nocase_collation
)

# Or, if you use SQLAlchemy you need to register
# the collation via an event
@sa.event.listens_for(sa.engine.Engine, 'connect')
def sqlite_engine_connect(connection, _):
    connection.create_collation(
    "UNICODE_NOCASE", unicode_nocase_collation
)
 

Kollationer har flere fordele i forhold til de næste løsninger:

1. De er nemme at bruge. Du kan angive sortering i tabelskemaet, og det vil automatisk blive anvendt på alle forespørgsler og indekser i dette felt, medmindre du angiver andet:
   

   CREATE TABLE test (text VARCHAR COLLATE UNICODE_NOCASE);
    

   Lad os for fuldstændighedens skyld se på yderligere to måder at bruge sammenstillinger på:
   

   -- In a particular query:
   SELECT * FROM items
       WHERE text = "Text in AnY case" COLLATE UNICODE_NOCASE;
   
   -- In an index:
   CREATE INDEX IF NOT EXISTS idx1 
       ON test (text COLLATE UNICODE_NOCASE);
   
   -- Word of caution: your query and index 
   -- must match exactly,including collation, 
   -- otherwise, SQLite will perform a full table scan.
   -- More on indexes below.
   EXPLAIN QUERY PLAN
       SELECT * FROM test WHERE text = 'something';
   -- Output: SCAN TABLE test
   EXPLAIN QUERY PLAN
       SELECT * FROM test WHERE text = 'something' COLLATE NOCASE;
   -- Output: SEARCH TABLE test USING COVERING INDEX idx1 (text=?)
    

2. Sortering giver uafhængig sortering med ORDER BY ud af boksen. Det er især nemt at få, hvis du definerer sorteringen i tabelskemaet.

Præstationsmæssige sammenstillinger har nogle ejendommeligheder, som vi vil diskutere yderligere.

3. Applikationsdefineret SQL-funktion

En anden måde at opnå case-usensitiv søgning på er at oprette en applikationsdefineret SQL-funktion (dokumentation):

import sqlite3

# Custom function
def casefold(s: str):
    return s.casefold()

# Connect to the DB and register the function
connection = sqlite3.connect("your_db_path")
connection.create_function("CASEFOLD", 1, casefold)

# Or, if you use SQLAlchemy you need to register 
# the function via an event
@sa.event.listens_for(sa.engine.Engine, 'connect')
def sqlite_engine_connect(connection, _):
    connection.create_function("CASEFOLD", 1, casefold)
 

I begge tilfælde create_function accepterer op til fire argumenter:

• navnet på funktionen, som den vil blive brugt i SQL-forespørgslerne
• antal argumenter, som funktionen accepterer
• selve funktionen
• valgfri bool deterministic , standard False (tilføjet i Python 3.8) – det er vigtigt for indekser, som vi vil diskutere nedenfor.

Som med sorteringer har du et valg – overbelast den indbyggede funktion (f.eks. LOWER ) eller opret ny. Vi vil se nærmere på det senere.

4. Sammenlign i applikationen

En anden måde at søge uafhængig af store og små bogstaver på ville være at sammenligne i selve appen, især hvis du kunne indsnævre søgningen ved at bruge et indeks på andre felter. For eksempel, i listOK kræves en sammenligning uden forskel på store og små bogstaver for elementer på en bestemt liste. Derfor kunne jeg vælge alle elementer på listen, normalisere dem til én sag og sammenligne dem med det normaliserede nye element.

Afhængigt af dine omstændigheder er det ikke en dårlig løsning, især hvis den delmængde, du vil sammenligne med, er lille. Du vil dog ikke være i stand til at bruge databaseindekser på teksten, kun på andre parametre, du vil bruge til at indsnævre omfanget.

Fordelen ved denne tilgang er dens fleksibilitet:I applikationen kan du ikke kun kontrollere lighed, men for eksempel implementere "fuzzy" sammenligning for at tage højde for mulige trykfejl, entals-/pluralformer osv. Dette er den rute, jeg valgte til listOK da botten havde brug for uklar sammenligning for at skabe den "smarte" genstand.

Derudover eliminerer det enhver kobling med databasen – det er simpel lagring, der ikke ved noget om dataene.

5. Gem normaliseret felt separat

Der er en løsning mere:Opret en separat kolonne i databasen og behold den normaliserede tekst, du vil søge på. Tabellen kan f.eks. have denne struktur (kun relevante felter):

Dette kan se overdrevent ud i starten:du skal altid holde den normaliserede version opdateret og effektivt fordoble størrelsen af ​​name Mark. Men med ORM'er eller endda manuelt er det nemt at gøre, og diskpladsen plus RAM er relativ billig.

Fordele ved denne tilgang:

• Det adskiller applikationen og databasen fuldstændigt – du kan nemt skifte.

• Du kan forbehandle normaliserede filer, hvis dine forespørgsler kræver det (trimme, fjerne tegnsætning eller mellemrum osv.).

Skal du overbelaste indbyggede funktioner og sorteringer?

Når du bruger applikationsdefinerede SQL-funktioner og kollationer, har du ofte et valg:Brug et unikt navn eller overbelaste indbygget funktionalitet. Begge tilgange har deres fordele og ulemper i to hoveddimensioner:

For det første pålidelighed/forudsigelighed når du af en eller anden grund (en engangsfejl, fejl eller med vilje) ikke registrerer disse funktioner eller sammenstillinger:

• Overbelastning:databasen vil stadig fungere, men resultaterne er muligvis ikke korrekte:

  • den indbyggede funktion/sortering vil opføre sig anderledes end deres tilpassede modparter;
  • hvis du brugte nu fraværende sortering i et indeks, ser det ud til at virke, men resultaterne kan være forkerte, selv når du læser;
  • hvis tabellen med indeks og indeks ved hjælp af tilpasset funktion/sortering bliver opdateret, kan indekset blive beskadiget (opdateret ved hjælp af indbygget implementering), men fortsætte med at arbejde, som om intet var hændt.

• Overbelaster ikke:Databasen fungerer ikke på nogen måde, hvor de fraværende funktioner eller sammenstillinger bruges:

  • hvis du bruger et indeks på en fraværende funktion, vil du kunne bruge det til læsning, men ikke til opdateringer;
  • indekser med applikationsdefineret sortering virker slet ikke, da de bruger sorteringen, mens de søger i indekset.

For det andet tilgængelighed uden for hovedapplikationen:migreringer, analyser osv.:

• Overbelastning:du vil være i stand til at ændre databasen uden problemer, mens du husker på risikoen for korrupte indekser.

• Overbelaster ikke:I mange tilfælde bliver du nødt til at registrere disse funktioner eller sammenstillinger eller tage ekstra skridt for at undgå dele af databasen, der afhænger af den.

Hvis du beslutter dig for at overbelaste, kan det være en god idé at genopbygge indekser baseret på brugerdefinerede funktioner eller sorteringer, hvis de får forkerte data registreret der, for eksempel:

-- Rebuild all indexes using this collation
REINDEX YOUR_COLLATION_NAME;

-- Rebuild particular index
REINDEX index_name;

-- Rebuild all indexes
REINDEX;
 

Ydelse af applikationsdefinerede funktioner og sorteringer

Brugerdefinerede funktioner eller sortering er meget langsommere end indbyggede funktioner:SQLite "vender tilbage" til din applikation, hver gang den kalder funktionen. Du kan nemt tjekke det ved at tilføje en global tæller til funktionen:

counter = 0

def casefold(a: str):
    global counter
    counter += 1
    return a.casefold()

# Work with the database

print(counter)
# Number of times the function has been called
 

Hvis du sjældent spørger, eller din database er lille, vil du ikke se nogen meningsfuld forskel. Men hvis du ikke bruger et indeks på denne funktion/sortering, kan databasen udføre en komplet tabelscanning ved at anvende funktionen/sorteringen på hver række. Afhængigt af bordets størrelse, hardware og antallet af anmodninger kan den lave ydeevne være overraskende. Senere vil jeg udgive en gennemgang af applikationsdefinerede funktioner og sammenstillingsydelse.

Strengt taget er kollationer en smule langsommere end SQL-funktioner, da de for hver sammenligning skal folde to strenge med små bogstaver i stedet for én. Selvom denne forskel er meget lille:i mine test var casefold-funktionen hurtigere end tilsvarende sortering med omkring 25 %, hvilket svarede til en forskel på 10 sekunder efter 100 millioner iterationer.

Indekser og ufølsom søgning

Indekser og funktioner

Lad os starte med det grundlæggende:Hvis du definerer et indeks på et hvilket som helst felt, vil det ikke blive brugt i forespørgsler på en funktion, der anvendes til dette felt:

CREATE TABLE table_name (id INTEGER, name VARCHAR);
CREATE INDEX idx1 ON table_name (name);
EXPLAIN QUERY PLAN
    SELECT id, name FROM table_name WHERE LOWER(name) = 'test';
-- Output: SCAN TABLE table_name
 

Til sådanne forespørgsler har du brug for et separat indeks med selve funktionen:

CREATE INDEX idx1 ON table_name (LOWER(name));
EXPLAIN QUERY PLAN
    SELECT id, name 
        FROM table_name WHERE LOWER(name) = 'test';
-- Output: SEARCH TABLE table_name USING INDEX idx1 (<expr>=?)
 

I SQLite kan det også gøres på en brugerdefineret funktion, men den skal markeres som deterministisk (hvilket betyder, at den med de samme input returnerer det samme resultat):

connection.create_function(
    "CASEFOLD", 1, casefold, deterministic=True
)
 

Derefter kan du oprette et indeks på en brugerdefineret SQL-funktion:

CREATE INDEX idx1 
    ON table_name (CASEFOLD(name));
EXPLAIN QUERY PLAN
    SELECT id, name 
        FROM table_name WHERE CASEFOLD(name) = 'test';
-- Output: SEARCH TABLE table_name USING INDEX idx1 (<expr>=?)
 

Indekser og sammenstillinger

Situationen med sorteringer og indekser er den samme:for at en forespørgsel kan bruge et indeks, skal de bruge den samme sortering (underforstået eller udtrykkeligt angivet), ellers vil det ikke fungere.

-- Using application defined collation UNICODE_NOCASE from above
CREATE TABLE test (text VARCHAR COLLATE UNICODE_NOCASE);

-- Index will be built using the collation
CREATE INDEX idx1 ON test (text);

-- Query will utilize index and collation automatically
EXPLAIN QUERY PLAN
    SELECT * FROM test WHERE text = 'something';
-- Output: SEARCH TABLE test USING COVERING INDEX idx1 (text=?)