[kpihus]

Meil on andmebaas erinevate hotellidega puhkusereisi broneerimiseks. Otsimise loogika on selline:

Otsime kuupäeva vahemiku ja tärnide järgi
Kui tagastati tühi tulemus, siis on kaks võimalust, kas ei olnud soovitud vahemikus sobivat hotelli, või ei olnud soovitud tärnidega hotelli.
Kui ei olnud soovitud vahemikus, siis peame ignoreerima lõpukuupäeva ja tagastama hotellid alguskuupäevast edasi
Kui ei olnud soovitud tärnidega hotelli, siis peame tagastama ühevõrra suurema ja ühevõrra väiksema tärnide arvuga hotelli.

Seega et kõik see ära katta, peaksime tegema järgnevad otsingud:

Tärnide ja kuupäeva vahemikuga
Tärnide +/- 1 ja kuupäeva vahemikuga
Tärnide ja ainult algus kuupäevaga
Tärnide +/- 1 ka ainult algus kuupäevaga.

Tundub et läheb pisut kulukaks seega peaks siin kuidagi optimeerima, aga endal on kuul veidi kokku jooksnud. Kas seda kõik saaks ehk kuidagi ühte päringusse pista ?

Baasiks on mysql.

[napoleon]

Ühte päringusse saad need ju kokku panna näiteks exists alampäringut kasutades, aga tõenäoliselt ei saa asja nii oluliselt efektiivsemaks.
Teine võimalus on agregeerida ja üritada having osas üleliigsed read välja visata, tõenäoliselt on mõnevõrra efektiivsem kui exists, aga peab pisut rohkem nuputama, et asi õigesti tööle saada.
Kui jõudlus reaalselt probleemiks on, üritaks mina ehitada mingi indeks tabeli, mida broneerides trigger-ga uuendatakse(igasuguste jamade vältimiseks võiks selle indeks tabeli aeg-ajalt ka üle arvutada). Kui kuulud nende hulka, kes arvavad, et trigger on saatanast, siis võib seda indeks tabelit muidugi ka äriloogikas uuendada, aga sellega tekib tegelikult suurem risk, et tabel sünkroonist välja läheb.

[ref]

Jah, kõike seda saab ühte suurde päringusse pista.

Kuna MySQLil puudub jätkuvalt CTE tugi, siis sul on kasutada peamiselt inline view aga ka temporary ja derived tabelid mida saab siis eelpool mainitud exists jupiga kokku panna.
Veidi sarnasel teemal on kirjutatud siin (üldiselt, CTE teema) - http://stackoverflow.com/questions/1382573/how-do-you-use-the-with-clause-in-mysql

Laias laastus - tekitad nt temp tabelid oma päringutele ja siis nt unioniga kokku tingimustega, mis välistavad laiendavad tulemused, kui kitsad on täidetud.
Sama saavutad ka inline view-dega (sisuliselt alampäringud), aga kuna neid vaja tõenäoliselt samal kujul mitmes kohas joinida tuleb SQL lohisev ning päris pikk.
Optimaalsuse kohapealt ei tohiks vahet olla, et kas on temp. tabeli või alampäringu pealt join - mootor peaks selle ikkagi tabelite peale taandama ning joinid reaalselt nende pealt tegema.

Üks variant on päringud ka paralleelselt käima lasta, ning kui kitsad päringud juba tulemusi annavad, need laiemad lisaotsingud ära canceldada (see sõltub nüüd rohkem sellest platvormist, millelt päringuid teed).

Muidugi, kui sa juba seda teinud ei ole, tasub profileerida ja mõõta kus kitsaskohad on, enne kui ennustama hakata ja kirvega optimeerimisele läheneda (võimalik, et ka andmemudeli muutmine, kui võimalik, aitab).

[sigakoer]

Kogu seda loogikat pole mõtet ühte SQL lausesse suruda. Tee kõigepealt kuupäeva/tärnide päring; kui see tulemusi ei anna, siis lõdvema kuupäeva ja tärnidega päringud lisaks. Pole mõttekas äriloogikat kõike ühte ulmelisse SQLi sisse vägistada, mille tööpõhimõttest pärast keegi aru ei saa ja täiendada ei oska.

[serk]

"Kogu seda loogikat pole mõtet ühte SQL lausesse suruda. Tee kõigepealt kuupäeva/tärnide päring; kui see tulemusi ei anna, siis lõdvema kuupäeva ja tärnidega päringud lisaks. Pole mõttekas äriloogikat kõike ühte ulmelisse SQLi sisse vägistada, mille tööpõhimõttest pärast keegi aru ei saa ja täiendada ei oska. " ei saa kuidagi nõustuda. Üks päring on alati kordades kiirem kui neli/viis päringut. Võimalikult palju alati kõik ühte päringusse.

Vaata üle kõigepealt andme set, mille sa aluseks võtad. Proovi põhiandmed kätte saada ühe selectiga ja neid siis kasutada järgnevates. tundub, et tärnide järgse filtreeringu saad kätte ja see kehtib kõigi tingimuste suhtes (+-1) .
Võid ka tuimalt unioniga erinevad äriloogilised selectid kokku lükata. Põhiandmeseti tõmbad viewsse ja sealt kasutad neid edasi järgmistes päringutes. Lisa filtreeringu teed juba UI või madalam tasemel.

[connor]

[serk]

Kindlasti ei ole pikka töösuhet mehega, kes näeb lahendusena erinevaid päringuid normaalse lahendusena- ei ole iroonia, seega kokku me töötama ei satu.

1 kasutaja puhul tehakse 4 päringut baasi
2 kasutaja puhul tehakse 8 päringut baasi
3 kasutaja puhul tehakse 12 päringut baasi
15 kasutaja puhul tehakse 60 päringut baasi

Normaalses booking süsteemis on korraga sadu kasutajaid sageli. Ja see on ainult üks baasiga suhtlemise osa. Ehitades kogu rakenduse sellises stiilis, on lõpptulemus juba eos teada.

Arhitektuurselt täiesti arulage lahendus. Pole olemas ühtegi päringut, mis ei ole loetav või debuggitav. Nagu iga java või php kood, on ka päringud vägagi debuggitavad.

Kasutades ühte main selecti andmete toomiseks, hakkab baas seda by default ühel hetkel cachima, võid ka forcida seda. Erinevate päringute puhul tekitad sa mõttetult palju IOd ja varem või hiljem maksab see kätte.
Kui me räägime mingist kodukootud eksperimentaalsest jupist, siis jumala savi kuidas sa selle probleemi lahendad. Kui ehitatad suuremat ja jätkusuutliku süsteemi, siis päringute arvu peale pead kohe alguses mõtlema hakkama.

[napoleon]

Enamasti on kasutajal serk õigus. Aga on ka erandeid. Näiteks ühes 4. põlvkonna keeles oli aruanne, mis kasutas päringut select a,b,c from a inner join b ....
Midagi müstiliselt keerukat selles päringus polnud ja indeksid olid ka olemas. Aga andmeid oli palju ja päring oli aeglane. Lahenduseks oli select a,b,c from a ja resultseti loopides sai iga rea kohta tabelist b päring tehtud. Tundub ebaloogiline, aga asja sai oluliselt kiiremaks. Igaks juhuks olgu täpsustuseks öeldud, et kõik toimus sünkroonselt ehk pärast ei lastud mitut päringut paralleelselt tabeli b pihta käima.
Põhjus miks kiiremaks sai oli see, et tabeleid puhverdati, aga kui mitmest tabelist päring teha, siis ei olnud puhvrist kasu.
Minu jutu point on selles, et alati peab arvestama ka konkreetse keskkonna ja vahendi iseärasustega ja mõnel juhul võib ka pealtnäha jabur lahendus parimaks osutuda.

Natuke OT aga mitte päris kontekstist välja. Serk, kui juba baasidest nii palju jagad, oskad ehk öelda kas tänapäevased baasimootorid optimeerivad asju paremini, kui teha sellest mölakast päringust view mitte kupatada otse baasi poole? Minu jaoks on see küsimus rohkem üldharivas mõttes, hetkel ma ühelegi konkreetsele probleemile lahendust ei otsi

[kpihus]

[wiinanina]

Kas t6esti on mysql selline 6nnetu andmebaas, kus puduvad protseduurid??? Annad parameetrid ette ja saad vastuse. Protseduuri sees juba otsustad, kui palju, mis tabelitest ja missugusi päringuid teed.
Endal seni kogemusi mssql ja oracle basidega ning nii eluv66ras kogu seda threadi lugeda.

[mikk36]

wiinanina, miks küsida, kui ei vaata ise? On olemas täitsa protseduurid alates 5.0 versioonist.

[wiinanina]