Amikor SQL független logika gyorsít

Volt egy esetem, amikor egy like-ot kellett felturbózni.
Az adatok így néztek ki (1 millio sor volt a táblában és folyamatosan nőtt):

A feladat a ‘kod11=2548796654’ részletet megkeresni az ‘url’ mezőben és listázni a hozzá tartozó sorokat.

A query adott volt, ezen kéne turbózni:

SELECT * FROM tábla WHERE url like '%kod11=2548796654%'

Kezdjük a szokás kérdéssel.
Kérdés: Miért nincs egy másik tábla is, ahol kulcs-érték párokba vannak rendezve ezek az adatok?
Válasz: Anno így lett elkészítve az adatbázis és most nincs idő refaktorálni.

Mit lehet tenni ilyenkor?

Az elméleti szakember itt felteszi a kezét, hogy ennyi volt, SQL-ben ennél többet nemigazán lehet tenni.
A tapasztalt szakember pedig már a kérdés pillanatában tudta a választ, ahogy azt is, hogy beszéltetni kell a fejlesztőt, mert lehet lesz kapaszkodó.

Jelen esetben két fontos információ hangzott még el a fejlesztőtől:
1.) A kod11 (2548796654) mindig egyedi érték lesz. (Megoldás: TOP 1)
2.) Mindig a friss információkra lesznek kíváncsiak (Megoldás: ORDER BY id DESC)

Egészítsük ki a lekérdezést:

SELECT TOP 1 * 
FROM tábla 
WHERE url like '%kod11=2548796654%' 
ORDER BY id DESC

Ez a megoldás 50X-es gyorsulást hozott és tartósan, mivel mindig garantáltan a tábla végéről kell adat.
Tehát mindegy, hogy mennyi sor van a táblában, a query mindig gyors lesz.

 

Mennyit tud segíteni egy kis beszélgetés?! 🙂

Sor konvertálás key-value párosra egyszerűen

Időnként szükség lehet oszlopkat sorokra konvertálni. Persze, jó az unpivot, de ha nincs semmi speciálisra szükségünk, csak egyszerű key-value párokra, akkor van egy sokkal univerzálisabb megoldás: xml oda vissza konvertálás.

Lássuk mire gondolok.

 

select
    [name],
    [state_desc],
    [user_access_desc],
    [page_verify_option_desc],
    [log_reuse_wait_desc]
from sys.[databases]
where [database_id] = 1

 

És akkor az univerzális query amiben csak a lekérdezésnek kell módosuljon:

 

declare @xml_data xml = (
select
    [name],
    [state_desc],
    [user_access_desc],
    [page_verify_option_desc],
    [log_reuse_wait_desc]
from sys.[databases]
where [database_id] = 1
for xml path
)

select
    t.c.value('local-name(.)', 'nvarchar(255)') as [Key],
    t.c.value('(.)[1]', 'nvarchar(255)') as [Value]
from @xml_data.nodes('//row/*') t(c)

 

 

Ennyire egyszerű 🙂

A GDPR és a brute force search

Most, hogy igazán beindult a GDPR lesz/van mit takarítani. Node, annyi az adat, hogy ki tudja már, hol és mit tárolunk?
Ugye ott a doksi (ha van), ami vagy friss, vagy nem, de most tételezzük fel, hogy friss.
Vajon biztosra ki mered e jelenteni, hogy a rendesen karbantartott doksi alapján el tudod/tudjátok készíteni az alkalmazást, ami a GDPR-nek megfelel?

Szerintem csak 1 biztos módszer van, amíg be nem járatódik/járatódott az összes előfordulási lehetőség, ez pedig a brute force keresés a db-kben.

De, hogy nehogy példa nélkül maradjatok. Pl, kéri Kiss Józsi, hogy töröld az adatait. Jó esetben firstName, lastName mezők. Rosszabb esetben, kommentek, chat-ek, egyéb log jellegű mezőkben is fellelhető lesz, ami egy doksiból nem feltétlen derül ki.