május 2018 havi bejegyzések

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ű 🙂

Reklámok

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.