Antwoord.

Achtergrond van de vraag:
Aanvankelijk werd SQL vooral gebruikt voor het werken met gestructureerde gegevens, waarbij zoeken in tekstvelden beperkt was tot eenvoudige operaties zoals LIKE. Met de groei van de hoeveelheid tekstuele informatie ontstond de noodzaak om snel en flexibel te zoeken in grote teksten: artikelen, berichten, blogs, enz.

Probleem:
Standaard SQL-tools (LIKE/ILIKE) functioneren slecht met grote hoeveelheden tekst en kunnen geen woorden effectief vinden op basis van relevantie, rekening houdend met morfologie of de afstand tussen woorden. Dit kan leiden tot prestatieverlies en te lange responstijden bij het zoeken.

Oplossing:
Voor dergelijke taken worden full-text zoekmechanismen (Full-Text Search, FTS) gebruikt, ingebouwd in databases, bijvoorbeeld Full-Text Index en speciale operators (CONTAINS, MATCH AGAINST, tsvector, tsquery). Dergelijke indexen bouwen een „woordenkaart” (“inverted index”) op, waardoor het zoeken in teksten tientallen keren sneller gaat.

Voorbeeldcode (SQL Server):

CREATE FULLTEXT CATALOG ftCatalog AS DEFAULT;
CREATE FULLTEXT INDEX ON Documents(Content) KEY INDEX PK_Documents;

SELECT * FROM Documents WHERE CONTAINS(Content, '"SQL programming"');

Kernpunten:

Functioneert op basis van speciale full-text indexen, gescheiden van gewone.
Ondersteunt zoekopdrachten met relevantie, lemmatisering, stopwoordenherkenning en complexe voorwaarden (NIET, OF, nabijheid).
Vereist onderhoud van de index bij massale gegevenswijzigingen — periodieke herindexering.

Misleidende vragen.

Wat is het verschil tussen zoeken met LIKE en full-text zoekopdracht?

LIKE is een eenvoudige vergelijkingsoperatie met een patroon, die geen indexen op tekst gebruikt, en is traag voor grote volumes. Full-text maakt gebruik van een speciale index en kan rekening houden met morfologie en relevantie.

Voorbeeld:

SELECT * FROM articles WHERE body LIKE '%database%';
-- traag, geen ranking

SELECT * FROM articles WHERE MATCH(body) AGAINST ('database');
-- snel, met ranking

Wat gebeurt er met de full-text index bij massale invoegen of verwijderen?

Na massale wijzigingen aan tekstvelden wordt de index verouderd (soms automatisch bijgewerkt, soms handmatig) en moet de index opnieuw worden opgebouwd om de prestaties te herstellen.

-- Voor MSSQL
ALTER FULLTEXT INDEX ON Documents START FULL POPULATION;

Kun je full-text indexen gebruiken voor zoeken in kolommen van het type JSON of XML?

Nee, er is geen directe ondersteuning voor de meeste full-text motoren voor JSON/XML-structuren; dergelijke gegevens moeten of in een tekstveld worden gehaald, of er moeten speciale parser/v externe tools (bijvoorbeeld Elasticsearch) worden toegepast.

Typische fouten en anti-patronen

Gebruik van de operator LIKE '%word%' op grote tabellen — catastrofale prestaties
Herindexering wordt niet uitgevoerd, zoekopdrachten worden irrelevant
Geen rekening houdend met de kenmerken van talen en stopwoorden
Indexeren van meerdere gigabytes gegevens zonder extra middelen

Voorbeeld uit het leven

Negatieve case

Een bedrijf had tientallen miljoenen records van artikelen opgeslagen. Voor het zoeken werd LIKE '%woord%' gebruikt. De IT-afdeling klaagde over regelmatige time-outs, gebruikers wachtten meer dan 10 minuten op resultaten.

Voordelen:

Geen extra licenties of instellingen nodig
Eenvoudige implementatie

Nadelen:

Zwakke prestaties, vooral op grote volumes
Onrealistische responstijden van het systeem
Onjuiste zoekresultaten (geen rekening houdend met de vorm van het woord)

Positieve case

Ze implementeerden Full-Text Search (FULLTEXT INDEX in MySQL). Het zoeken gebeurde tot 100 keer sneller, het was mogelijk om naar „vergelijkbare” woorden en zinnen te zoeken, en er werd ranking toegevoegd.