Normalizirana struktura - query

EXISTS

SELECT * FROM master m
where exists (Select 1 FROM detail d WHERE d.id = m.id = d.X = 'A')
and exists (Select 1 FROM detail d WHERE d.id = m.id = d.X = 'B')

COUNT ti prešteje rezultate, za izpis si lahko dodas kar sam ID

To vse jasno, ampak

OFFTOPIC

zakaj deluje

SELECT COUNT(DISTINCT data)=2

kot je napisal technolog, pa četudi se je samo za copy/pastal.

in kaj potem rezultat pomeni.

Če je COUNT(DISTINCT data)=2 v having delu mi je kajpak jasno kaj to je.

Ni res, ni počasno. Če imaš index na detail.id, je group by po id hiter, data polj je pa itak malo. V bistvu je hitrost ista, kot z exsist stavki, le da če imaš recimo izbor 100 črk nimaš "en mega" velikega query-a.

kot rečeno zgoraj:

sam problem je da je teh A,B,... x ...

A,B,... so pri meni cifre tko da je tega lahko neomejeno, trenutno je možnih x of izbora približno tridesetih na 1 id. Id- jev je pa zdaj okol 6000
Sice mi vse obratuje samo je počasno, pa malo študiram kako bi drugače. Distinct ni treba ker mam indexe tko postavljene da duplikatov sploh ne pusti vnest.

Tega naj ne bi delal, je v nasprotju s pravili normalizacije. Če že, potem uporabit BIT tip polje.

Ne vem, če lahko podpreš tole z virom...

Ampak - pravila normalizacije se lahko kršijo z res utemeljenimi razlogi :) In še to zgolj 3. in 4. NO.

WarpedGone je 5. okt 2011 ob 16:23 izjavil:

Počasen je konkreten querry ki ugotavlja ali ima nek ID zahtevane A,B... al kaj drugega?

Ker če je to počasno, potem so možne variante kjer te IDje sestavljaš.
Praviš da so cifre, na nivoju master zapisa lahko dodaš neko polje FLAGS tipa STRING, katero se usklajuje avtomatsko ob insert,delete,update v detail tabelo.
Recimo, če pa nek ID v detail tabeli vrednosti 1,5,7,9 potem je polje flags 1,5,7,9.

In namesto da vsakič posebej češeš detail tabelo nardiš enostavno select * from master where flags = '1,5,7,9'. Tle gor počiš še index in zadeva leti.

Ja zdaj mam nekaj takega samo da nimam zadevnega polja , ampak uporabljam group_concat od mysql.

Sicer pa, glede normalizacije


master

id     obvezen_podatek_ki_ni_nikoli_null    
1      recimo width slike v galeriji 1  
2      recimo width slike v galeriji 2
....

detail - lastnosti objekta na sliki, recimo da so to gobe

id     opcijski_podatek    
1      na lesu  
1      nima beta
2      na lesu
....

v primeru da tole ne bi bilo normalizirano, pol je iskanje simpel (gob, ki so na lesu in brez beta). Vprašanje je le kolk indeksov bi bilo potem treba imet za hitro iskanje.

ker pa je normalizirano pa moram najprej select iz detail (v smislu kot v prejšnjih postih) in nato join nazaj na master, zato da dobim zraven še width od slike


Drgač pa speed je precej odvisen od baze. Kar (specifičemn primer) npr. mssql naredi za tren oka, MySql melje in melje ......

select  id_galery, count(id_galery)
from    galery_optional_inf as g
where   color in ('blue', 'red')
        and not exists(
            select  null
            from    galery_optional_inf as g1
            where   g.id_galery = g1.id_galery
                    and g1.color not in ('blue', 'red'))
group by id_galery
having  count(color) = 2

Bo pa query optimizer verjetno zgeneriral enak plan, kot za join; tako je izbira 'not exists' ali join stvar preference, kaj ti je bolj berljivo in razumljivo.