[Timukas0]

On 4 tabelit:
1) recipe_recipes (recipe_id, recipe_name, ...)
2) recipe_ingredients (ingredient_id, ingredient_price, ...) ingredient_price ehk hind on ühe ühiku kohta
3) recipe_ingredient_mapping (map_recipe, map_ingredient, map_quanitity)
4) recipe_related_recipes (related_parent, related_child, related_required)

Ühesõnaga on komponentide tabel, igal komponendil oma hind. Siis on retseptide tabel, igal retseptil nimi ja muud andmeid. Iga retsept koosneb kindlast arvust ja kindla kogusega komponentides. Igal retseptil võib olla seotud retsept, mis on kas nõutud (related_required = 1) või valikuline. Mul on vaja saada kõik retsepti andmed ning kogu retsepti hind.
Hind = SUM(iga retsepti komponendi hind * komponendi kogus) + SUM(iga seotud ja nõutud retsepti hind).
Ise tulin sellise lahendusega lagedale, aga äkki keegi oskab paremini:

[mirko28]

See päring on praegu kujul:

[Timukas0]

GROUP BY oli tõesti puudu.

MYSQLil on olemas EXPLAIN käsk, aga see midagi kasulikku (mulle) ei ütlenud, siis kasutasin kiiruse võrdlemiseks lihtsalt kogu tabeli küsimist ja vaatasin, kaua aega läheb.
(ema X MuudHulgad) + (Lapsed X Muudhulgad) oli tõesti kiirem, aga parima tulemuse sain hoopis alampäringuga:

[serk]

Mõned vead:

Kõige hullem asi mida sa SQLi kirjutades teha saad on kasutada funktsiooni andmete toomiseks või siis sinu puhul siis select selecti sees - see on kõige aeglasem ja baasi koormavam viis üldse.

Explain Plan on arendaja parem käsi, õpi selgeks! Ma ei kujuta ette, kuidas ilma selleta üldse normaalseid päringuid kirjutada võimalik on ...

Ei tea küll mis MySQLi versiooni kasutad, kuid minu teada on MySQLis juba kasutusel Oraclega sarnasd analüütilised funktsioonid ja juba üsna pikka aega - väga võimsad vahendid päringute muutmiseks tunduvalt kiiremaks, jällegi, vii kurssi ennast nendega.

[mirko28]

[Timukas0]

MySQL versioon 5.1.36.
Uurisin natuke. Esimese postituse päring, kui kõik read küsida, (WHERE lõpust ära ja Group BY asemele) on 9 korda aeglasem kui minu järgmise postituse päring (phpMyAdmini näidatud aja põhjal). Põhjuseks oli "Copying to tmp table", millele kulus esimese päringu korral 90% ajast. Seega jääb õhku küsimus, et kas ikka on esimene päring parem (kui jah, siis miks)?

Mis puutub analüütilistesse funktsioonidesse, siis ma sain aru, et neid MySQLis ei ole, aga neid saab emuleerida. Samas ei näe, kuidas see peaks mind aitama.

[mirko28]

[Timukas0]

Antud lehel peab jälgima, millal räägitakse MySQL-ist ja millal muust. MySQLil ei ole OVER-klauslit. Pealegi sain ma aru, et analüütilised funktsioonid on mõeldud selleks, et GROUP BY-d kasutades ei läheks infot kaduma. Mul seda probleemi pole.

Väike teemavahetus. Kui komponentide (ingredient) hinda muuta, siis peaksid vanad hinnad ka alles jääma. Tegin uue tabeli hinnad veergudega komponent, hind, kuupäev (tegelikkuses pole pealkirjad päris samad). Komponentide tabelisse jätsin hinna veeru alles. Kui kasutaja komponendi hinda muudab, siis lisan uue hinna hindade tabelisse kuupäevaga ja muudan komponentide tabelis ka. Aga kuidas käituda, kui kasutaja soovib mitut hinda korraga muuta. Kas lihtsalt iga komponendi korral 2 päringut (lisada uus hind hindade tabelisse ja muuta hind komponentide tabelis) või teha midagi, mis nõuaks vähem päringuid.

[mirko28]

[Timukas0]

Ma just mõtlesin seda, kuidas PHPs andmebaasiga suhtlemine teha. Näiteks on kasutajal vaja 100 komponendi hinda muuta korraga. Kas teha php-ga kokku kokku 200 mysql_query-t (iga komponendi kohta 2), või siis näha vaeva ja vähendada vaja minevate päringute arvu.

[Fukiku]

Mul tekkis see küsimus, et kui juba sellist lahendust kasutatakse, kas siis ei oleks mõistlik hindade tabelisse tekitada veerud id, hind, kehtivuse_lopp ja komponentide tabelisse mitte hinda numbriliselt salvestada, vaid viidata kehtivale hinnale id kaudu? Andmete dubleerimine kahte tabelisse ei tundu hea mõte olevat andmebaasi disaini mõttes.

[mirko28]

MySql-is näib olema võimalik andmebaasi protseduure teha:
http://dev.mysql.com/tech-resources/articles/mysql-storedprocedures.html

siis sul võiks ju olla selline üks andmebaasi protseduur, mida välja kutsud:

[Timukas0]

Võtsin kasutaja Fukiku ideest kinni. Tabelil hinnad nüüd neli veergu: id (auto increment), komponendi_id, hind, kuupäev (current timestamp) ja komponentide tabelis on veerus `hind` vastava hinna id. Paljude komponentide muutmisele pakuks siis sellise lahenduse: php-ga teen umbes sellise päringu (kuupäev t:

[Fukiku]

Ma päeval vastasin umbropsu ja lühidalt. Seega, mis halvasti, see uuesti

Ühesõnaga, mina jätaks su hindade tabeli nii, nagu ma enne soovitasin (id, komponent_id, hind, kuupäev) ja komponentide tabelisse viidet hinnale üldse ei panekski.

Siis esiteks oleks hinna lisamine lihtsam, piisaks ainult insert lausest hindade tabelisse (komponent_id väärtust sa ju lisamisel tead, muud aga pole vaja).

Hinna pärimiseks sobiks midagi taolist:

[mirko28]

Tere,
Hiljem saab olema sellise lahendusega andmebaas aeglane.
Ajaloo tabel saab olema Süsteemi kõige aeglasem tabel, ja seda peaksite tee siis kogu aeg join-idesse lisama. Lisaks jääb veel arusaamatuks, kuidas andmebaasilt vastust saada, millise rea salvestamine andmebaasi vea andis.
MySql-is polegi kollektsioone vist, tuleb komaliste koostada stringide näol, kui on kollektsioonide vajadus. Ma soovitaks teha andmebaasi protseduuri, mis kollektsiooni sisendiks võtaks, ja väljastaks, missugune rida vea andis. Arvan, et see protseduur oleks kiire ja hiljem toote jooksva hinna pärimine oleks ka normaalne.


---

Võib-olla siiski ei tulegi aeglane lahendus, mida pakute siin! Andke siis kunagi utlevikus teada, kas perfoomants on okei! MySql-is saab ka partitsioneerida tabeleid, seda võiks ajaloo tabeli jaoks uurida.

[Timukas0]

Fukiku, sinu kood kahjuks ei tööta. Toimiks kas selline:

[mirko28]

Hinnaveeru selline dubleerimine on lühidalt öeldes "kiire aga hallatamatu" lahendus. Hallatamatu on ta selles osas et tuleb hallata, et dubleeritud andmed oleksid süngis, aga seda on raske tagada. Kiire on see lahendus, kuna tegu on eelarvutusega. Andmebaasi indeksid on eelarvutuslik ja dubleeriv nähtus, mis saamuti tekitab ohu, et see süngist välja läheb, kuid me ei pea indekseid kuigi palju ise haldama, andmebaasimootor teeb seda ise, indeks on korras kogu aeg. Kuid dubleeritud Hinnaveerge süngis hoida on raske, varem või hiljem miski juhtub ja ongi üks kahest väärtusest erinev. Niiet "kiire aga raskelt hallatav" asi on üldiselt see dubleerimine. Sedalaadi dubleerimise lahenduse juurde tuleks ilmselt alles siis tulla, kui kõik muud variandid on ära proovitud, ja tõepoolest perfoomansit muul traditsioonilisemal viisil parandada ei saa. Samas minuarust selline dubleerimise häkk tundub teoorias huvitavana, võiks proovida praktiliselt.

Kui mul oleks veebileht, kus oleks 100 tekstikasi, siis võiks ju öelda, millises tekstikastis on vale väärtus, kus ma ise neist 100 kastist selle vale üles oskaks leida.

[Timukas0]

Põhimõtteliselt ma ei dubleeri hinna veergu. Komponentide tabelis on hetke hind ja hindade ajaloo tabelis on hindade ajalugu. See, et mingi komponendi ajaloo tabeli viimane kirje kattub kattub hetke hinnaga on kokkusattumus :d. Jätab võimaluse kasutada ka selliseid hindu, mida pole vaja või ei tohiks ajaloo tabelisse salvestada (kuigi hetkel sellist funktsionaalsust vaja ei lähe).

[mirko28]

Toote käesoleva hinna jaoks võiks sobida selline päring:

[Timukas0]

Hindade ajaloo tabeli struktuur on selline

[mirko28]

Foorumid ongi hea koht, kus saab programmeerimist õppida. Teine hea koht on töökoht, kus on hea mentor-töökaaslane, kellega lahenduste üle arutada, kuid sellist kaas-töötajat paljudes töökohtades ei leia.

--

Lisaks mõned aspektid andmete dubleerimise kohta, mida aastakümnetega välja kujunenud hea tava heaks ei kiida, aga mida siiski tehakse järgmiste põhjustega:

1. Kui juhtub olukord, et tabeli T üle ei taheta anda isikule S õigusi andmeid küsida, siis on üheks lahenduseks dubleerida andmeid andmebaasis, tuua/dubleerida veerg sinna tabelisse kuhu on ligipääs olemas.
2. Andmete küsimise operatsiooni perfoomansi tõstmine. Jääb ära kulukas join.
3. Andmebaasi tasemel andmete turvalisuse tagamine. Häkker ei saa muuta parooli-veergu niilihtsalt, kuna andmebaas takistab seda öeldes et see veerg on sõltuv ühest teisest dubleeritud veerust, referential integriti vms kaitseks andmemuudatust.

[serk]

[mirko28]

Ja veel ka neljas põhjus:

4. Andmebaasi peale ehitatud tarkvara on piirangutega, mis teeb dubleerimise ainuvõimalikuks lahenduseks.

Seega 4 juba, üritan veel siia tuua neid.

[Fukiku]

[Le Inc]

Pole küll MySQL aga Oracle (sarnased ).

Miks peale oracle service restarti suurest tabelist lugemise kiirus (select * from) langeb ~11 sekilt ~2 sekile? See on muidugi tore, aga küss selles miks ta päeva jooksul jälle 11 sekile maandub? Kas asi on mingites indeksites vms? Kuidas saaks asja "jäädavaks" teha. Ehk mõni spets teab.