☰

» »

Optimizacija MySQL - query / tabela

Optimizacija MySQL - query / tabela

PandaFlow2 ::

Vremenske podatke zbiram v tabelo s sledečo strukturo: - id, - time (time), - station (int, korelacija v tabelo s postajami) - temp (double), - rh (double) Zadeva ima približno 5 novih vrstic vsako minuto, tako da se vrstice nabirajo kar hitro. Podatke prikazujem v graf (zajem podatkov je s PHP) s takšnim queryjem za zadnja 2 tedna: 
SELECT ROUND(AVG(UNIX_TIMESTAMP(time))) AS time,
ROUND(AVG(temp), 1) AS temp, ROUND(AVG(rh), 1) AS rh
FROM weather_new
WHERE time > NOW() - INTERVAL 2 WEEK
AND station = " . intval($row['id']) . "
GROUP BY time DIV(60 * 60)
ORDER BY time ASC
Težava je v tem, da je query po kakšnih 2 tednih postane zelo počasen, če imam v tabeli podatke za 2 meseca (400k+ vrstic), je generation time za takšen query tudi par sekund. Bi se dalo kako optimizirati strukturo tabele, indekse ali query da bi vse skupaj delalo hitreje pri večji količini podatkov?

jl ::

Kako pa imaš nastavljene indexe? V kolikor jih nimaš, ti gre query sekvenčno čez bazo in posledično z velikostjo baze tudi čas narašča.

Invictus ::

Odvisno od ostalih querijev, ampak lahko si narediš arhivsko tabelo. Ali pa zbrišeš podatke, če jih ne rabiš ...

Lahko si tudi narediš vmesne tabele, kjer shranjuješ povprečne vrednosti. In to tabelo nafilaš preko trigerjev.

Danes prostor pač ni več tako dragocen kot včasih ;).
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

illion ::

si ze dal "explain" pred select in pogledal kako bi lahko optimiziral?
lahko bi recimo naredil tud dodatno tabelo in jo dnevno polnil s statisticnimi podatki trenunega dneva in potem uporabljal te podatke za (dokaj tocne) kalkulacije..

Zgodovina sprememb…

  • spremenil: illion ()

prozac ::

group by in order by znata bit pozresni operaciji.

Jaz bi naredil podobno kot je predlagal Invictus - naredil novo tabelo, kjer bi bili samo ze izracunani podatki, da bi vsakic klical samo tako poizvedbo:

SELECT
  time,
  temp,
  rh
FROM weather_current;


Poleg tega naredis job / proceduro / trigger(samo v skrajnem primeru), ki ti izracunava podatke, polni tabelo _current in brise odvecne podatke. Seveda sta tudi indeks in pk obvezna.

insert into as
SELECT ROUND(AVG(UNIX_TIMESTAMP(time))) AS time,
ROUND(AVG(temp), 1) AS temp, ROUND(AVG(rh), 1) AS rh
FROM weather_new
WHERE time > NOW() - INTERVAL 2 WEEK
AND station = " . intval($row['id']) . "
GROUP BY time DIV(60 * 60);


delete from weather_current
where time <= (NOW() - INTERVAL 2 WEEK);

PandaFlow2 ::

Razen primary indexa na IDju ni postavljenih nobenih indeksov. Any ideas?

Hvala za ideje o shranjevanju starih podatkov, trenutno delam nekaj podobnega, ampak je samo cut-paste, nobenih izračunov povprečij za graf. Bom malo sprobal kako bi šlo.

Apple ::

Kreiraj fat indeks (vsa polja), tako ti ne bo delal table toucha pri selectu. ID bi jaz zbrisal ven.
1x mesec spravi stare zapise v arhivsko tabelo, ki je lahko klon originalne... Edino ne bos rabil takega indeksa na njej.
LP, Apple

fx ::

Upam da sem izbral pravo temo. Zanima me kako narediti oz. če je moj pristop dober ali pa se ga naj lotim drugače - prvič konfiguriram nekaj takega v taki rasežnosti.
Delam na sistemu kateri bo predvidevam v roku letu dni imel več kot 2 miljona zapisov. Opravljale se bodo meritve tako da bo tabela sestavljene nekako tako:
id (int)
value1 (float)
value2 (float)
...
valueN (float) 
systime (timestamp) // utc čas

Problem se mi pojavi da 2 miljona točk je malo težko hitro izrisat v brskalniku. Zato razmišljam da bi naredil dodatne tabele. Torej bi imel :
data, 
data_hour,
data_day,
data_month

Kot je vidno iz imen tabel bi potem s pomočjo crontaba izvajal skripte, ki bi računale povprečne vrednosti glede na časovno obdoboje in ga zapisale v strezno tabelo.

Prikaz podatkov v grafu pa bi deloval obratno letne ravni na minutno - odvisno kako veliki razpon izbereš.

Sedaj pa me zanima če je to dober pristop do problema ali je pa obstaja še kaj bolj elegantnega in hitrega.

Hvala.
Lep pozdrav,

fx

FX6300B ::

in kaj misliš imet v tabeli data, data_hour,data_day,data_month, če jaz prav zastopim bi imel v tabeli data podatke v data_hour pa uro tega zapisa?

če misliš tako kot je zgoraj napisano je to bedarija ti lahko uporabiš systime ki bo enak času ko je bil dodan no z raznimi funkcijami kot so month() day() lahko potem iz tega timestampa dobiš ven mesec, leto, datum, uro karkoli želiš :D potem ko pa želiš glede na časovno obdobje pa uporabiš v pogoju BETWEEN nekaj AND nekaj :D
May the force be with you!

Zgodovina sprememb…

  • spremenil: FX6300B ()

FX6300B ::

npr 

Select * from ime_tabele
Where MONTH(SYSTIME) BETWEEN 1 AND 3

to ti potem izpiše vse zapise med januarjem in marcem
May the force be with you!

Zgodovina sprememb…

  • spremenil: FX6300B ()

fx ::

v data_hour bi bila povrečna vrednost meritev zadnje ure in tako naprej.

Zanima me potem, kako potem rešiš da hitro prikažeš približek grafa kjer imaš v bazi 2 milijona vrstic med prvim in zadnjim vneseno vrstico, ker te pač zanima če se pojavljajo intervali na grafu, ki so podobni - pač za lažje analiziranje.

Ker funkcije kot so month in podobne ter between poznam :D.

Razen če lahko sestavim taki sql stavek, ki sproti računa povprečno vrednost glede na obodobje na posamezni dan ali mesec. To če ne motim bi moral imeti select v selectu.
Lep pozdrav,

fx

s1l3 ::

Predvidevam da ne bos direkt iz baze dal v graf in je se nekaj vmes. S tem vmes naredi karkoli ze potrebujes, racunaj povprecja ipd.

SasoS ::

Verjetno bi bil dovolj index na timestampu.

prozac ::

2 mio vrstic niti ni veliko. če ti uspe vse podatke shraniti v tabelo, da jih za prikaz na grafu samo bereš in nič sproti ne računaš, potem bi ti moralo delati zelo hitro.

Prvi pogoj pa je, da ugotoviš kaj točno želiš prikazovati na grafu in te podatke ustrezno shraniš v tabele.
Naredi eno tabelo, ki ima notri samo najbolj osnovne podatke, nato pa napišeš proceduro, ki te podatke obdeluje, izračunava povprečja, razlike,... in to drugo tabelo uporabiš za prikaz podatkov v grafu.

DBMS orodja poznajo razne analitične funkcije kot so sum, min, max, avg, least, greatest, first_value, last_value, lead, lag...
lahko pa uporabiš kake window funkcije sum(data) over (partition by ... order by ... rows preceding...) as delni_znesek, rank()over()........

Zgodovina sprememb…

  • spremenilo: prozac ()

halozan ::

PandaFlow2 je izjavil:

Razen primary indexa na IDju ni postavljenih nobenih indeksov. Any ideas?

Hvala za ideje o shranjevanju starih podatkov, trenutno delam nekaj podobnega, ampak je samo cut-paste, nobenih izračunov povprečij za graf. Bom malo sprobal kako bi šlo.


Obvezno indeks na time + station. To bi potem moralo delovati zelo hitro.
Kako pa imaš rešene arhiviranje podatkov, saj slej kot prej tabela naraste in tudi podatki verjetno ne bodo vse aktualni.

Ena od rešitev je tudi time partitioning, particioniranje tabele na podlagi časa (npr. vsak mesec svoja particija). Potem lahko select delaš samo po tej particiji.

WarpedGone ::

Particioniranje tabel je upravičeno, če lahko 'stare' podatke premakneš na kak drug medij. Dokler pa le zlagaš tabelo zram tabele, je to nonsense.
Točno enak performančni efekt se doseže z ustreznim indeksom, imaš pa manj solate.

Kot svetovano zgoraj: Why The F nimaš indeksa na poljih, po katerih se omejuješ?
Poleg tega premisli še časovno granulacijo, a res nucaš čas shranjen na mikrosekundo natančno al ti zadostuje recimo cela ura? Tako bo index bistveno manj razvejan in posledično za drekec hitrejši (in manjši).
Zbogom in hvala za vse ribe

FX6300B ::

glede id-ja je res kar bolje če ga ni in imaš potem na času index tudi če boš kaj povezoval med tabelam, je vseeno če imaš kar preko časa
May the force be with you!

Zgodovina sprememb…

  • spremenil: FX6300B ()

webmaher ::

Imam bazo v kateri so glavni podatki v 8 tabelah (InnoDB)....Tabele imajo od 2 pa največ 4MB podatkov in v povprečju okoli 6000 vrstic... Spletna stran deluje OK, podatki se takorekoč naložijo v momentu...
Zaradi avtomatizacije pa bi sedaj rad "razbil" vsebino 8 tabelc na okoli 200 tabelc... Zdaj me pa zanima ali bo to kaj vplivalo na odzivnost spletne strani in obremenjenost strežnika saj bo potrebno za prikaz vstopne spletne strani podatke vleči iz vseh 200 tabelc, zdaj je potrebno samo iz ene...

Hvala za odgovore :)

Invictus ::

Čisto na uč...

Temu ravno ne bi rekel optimizacija ;).
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

webmaher ::

imaš POPolnoma prav, ni optimizacija MY SQL baze je pa optimizacija dela... jaz potem iz sence s pirom v roki samo nadziram, če se je osvežila spletna stran popolnoma avtomatsko :)

Zdaj mi pa prosim resno odgovori na vprašanje, ki ga še malo obrnem na glavo :)
Ali je morda bolje da dam vse kar v eno tabelo, ki bi ob pogledu v bližnjo-daljno bodočnost lahko imela največ 100MB in okoli 200.000 vrstic?

WarpedGone ::

Webmaher ...

Poguglaj kaj je to VIEW.
Zbogom in hvala za vse ribe

webmaher ::

res lepo pomagate...bom si spremenil ime v cepec_sem_bogmi_pomagi :)

torej gugl je naš najbol prjatu tut če z ingliš nisi na ti, forum pa služi samo za usmerjanje cepcev ala jaz :))

cleanac ::

Seveda bo vplivalo, če razbiješ na 200 tabel, kaj pa si mislil.

Povej raje konkretni primer za kaj se gre pa ti bo že nekdo pomagal. Zakaj bi ločil po posameznih tabelah, če gre za isto strukturo podatkov? Kaj s tem pridobiš? Morda iščeš najlažjo/najhitrejšo rešitev in ne optimalno?

webmaher ::

s tem pridobim popolno ali skoraj popolno avtomatizacijo osvežitve podatkov v tabelah. Gre se za tv sporede...

zdaj imam en dan za vseh 182 tv kanalov v eni tabeli...
po novem pa bi imel vse dneve enega TV kanala v svoji tabeli in bi seveda zato rabil 182 tabel...

Tako bi lahko za vsak Tv kanal prilagodil avtomatsko kdaj in kolikokrat naj se updejta in to seveda avtomatsko...

Zdaj pač moram vse naenkrat in ročno...ker seveda ne morem dobiti vseh ob isti uri moram pač čakat, da dobim vse updejte...

WarpedGone ::

@cepec_sem_bogmi_pomagi:

1. razbijanje 1 tabele na 200 njih s povsem enako strukturo je obupna ideja, za vzdrževanje in za izvajanje
2. kakšen mehanizem updatanja imaš to, da ni sposoben spremenit samo dela vsebine tabele ampak kr komplet celo?
3. tudi če maš tak dumbass sistem, ga lahko na finto vržeš preko pogledov ampak zopet 200 njih bo sicer normalno hitro delalo bo pa to bruhanje od vzdrževanja
4. zato zopet nazaj k točki 2: sistem posodablanja spimpaj tako, da ne bo stran metal komplet vsebine ampak samo vsebino konkretnega programa. Če maš občutek, da to ni možno ... natuhtaj in spremeni način posodablanja
Zbogom in hvala za vse ribe

webmaher ::

tenk yu veri mač mr. @WarpedOne :)
trenutni sistem deluje sledeče:

najprej ročno, z makroji in tudi avtomatsko (xml spored) obdelam najnovejšo vsebino potem pa z doma narejenim programom naredim sql tabelce z zadnje osveženimi podatki, se povežem v bazo, program sam preimenuje obstoječe stare tabele in jih nadomesti s temi novimi... preimenovanje in upload novih se izvede v cirka 10 sekundah (4tabele).
Če je šlo karkoli narobe kar se praktično ne more zgoditi samo izbrišem na novo naložene tabele in stare preimenujem nazaj...

Torej ti predlagaš naj se obstoječe tabele obdržijo program se pa popravi tako, da bo najprej preveril id postaje v obstoječi in v novi, potem pa zbrisal podatke v obstoječi in jih nadomestil s temi novimi...

WarpedGone ::

No vidiš, sej ni tko težko :)
Zbogom in hvala za vse ribe

Kroos ::

Si bom kar to temo sposodil za svoje vprašanje, in sicer me zanima kako določiti maksimum vrstic / podatkov v neki MySQL tabeli?

No, če na hitro povzamem: Imam neko tabelo v katero se na 1 minuto zapisujejo vrednosti meritev. Ta tabela je sestavljena iz ID naprave (INT), timestamp-a ter 31 meritev (SMALLINT). Trenutno ima okoli 1 milijarde zapisov v tej tabeli in zato me malce skrbi, kakšen je sploh maximum oz. kako vedeti kdaj se lahko začnejo težave?

O tej tematiki sem že bral na Stack Overflow-u, ampak je dejansko toliko nekih različnih odgovorov, da človeka zmede vse skupaj. Ena od (logičnih) teorij je bila, da je število vrstic odvisno od največje možne vrednost AUTO_INCREMENT polja, torej če je UNSIGNED INT je pač to 4,294,967,295, ampak ga na tej tabeli ne uporabljamo. Druga teorija je pa, da ima InnoDB limit velikost tabele na 64 TB.

Kaj je sedaj res oz. je kakšna tretja varianta, kako to preveriti? Kako se vi spopadate z velikimi tabelami, ki jih ne morete razbiti na manjše (mogoče povprečenje starih podatkov na 5 minut)?

MisterR ::

Napisal si da jih ne morete razbiti na manjše, zakaj ne? A so vsi podatki aktivni? Ker drugače bi starejše podatke skladiščil v drugi bazi.

Invictus ::

Odloči se za interval, kjer so podatki aktualni.

Za neaktualne podatke se odloči, ali jih sploh še potrebuješ v raw obliki.

Če jih ne, jih sumariziraj, povpreči, ali pač kaka druga metoda ter jih shrani v arhivsko bazo.

Kljub vsemu se boš moral pa enkrat odločit da pobrišeš še arhivske podatke...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

MisterR ::

Zakaj bi brisal arhivske podatke? Tega se ne dela. Podatke samo prestavljaš s kupa na kup.

Invictus ::

Zato, ker postanejo nepotrebni??!?!?!? In ker prostor kljub vsemu stane?

Zakaj bi hotel imeti minutne odčitke ene naprave čez 20 let? Hording fetish ?!?!?

Kaj pa če imaš 100.000 odčitkov na minuto?
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

Mavrik ::

MisterR je izjavil:

Zakaj bi brisal arhivske podatke? Tega se ne dela. Podatke samo prestavljaš s kupa na kup.


Tako je, premakneš podatke po določenem času v drugo bazo / tabelo / ali dump za arhiv je v večini primerov ok. Seveda avtor ni napisal kakšen je vzorec dostopa in kakšna je količina.

Invictus je izjavil:

Zato, ker postanejo nepotrebni??!?!?!? In ker prostor kljub vsemu stane?

Zakaj bi hotel imeti minutne odčitke ene naprave čez 20 let? Hording fetish ?!?!?

Kaj pa če imaš 100.000 odčitkov na minuto?


A si ti pri svetovanju strankam tudi najprej neki zmisliš in potem začneš pizditi na osnovi te izmišljotine? Nikjer ni napisal da bere 100.000 odčitkov na minuto. Nikjer tudi ni napisal da lahko podatke kar tako zavrže in da so podatki sploh takšni da se karkoli da "povprečiti". Nekaj kar nekaj tumbat na pamet no.
The truth is rarely pure and never simple.

Zgodovina sprememb…

  • spremenil: Mavrik ()

krneki0001 ::

Iz produkcijske tabele se vedno prestavi v ARH tabelo vse zapise, ki niso aktualni za uporabo. S tem ti sistem omogoča hitrejše poizvedbe in manj problemov.

Invictus ::

Mavrik je izjavil:


A si ti pri svetovanju strankam tudi najprej neki zmisliš in potem začneš pizditi na osnovi te izmišljotine? Nikjer ni napisal da bere 100.000 odčitkov na minuto. Nikjer tudi ni napisal da lahko podatke kar tako zavrže in da so podatki sploh takšni da se karkoli da "povprečiti". Nekaj kar nekaj tumbat na pamet no.

Samo življenjske izkušnje ukvarjanja ravno s temi podatki. Raznimi monitoringi...

Stranke hočejo imeti neskončen arhiv, potem pa pizdijo, ko morajo dokupit diske. Arhivski podatki kar naenkrat postanejo nepomembni...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

Zgodovina sprememb…

  • spremenil: Invictus ()

MisterR ::

Invictus je izjavil:

Zato, ker postanejo nepotrebni??!?!?!? In ker prostor kljub vsemu stane?

Zakaj bi hotel imeti minutne odčitke ene naprave čez 20 let? Hording fetish ?!?!?

Kaj pa če imaš 100.000 odčitkov na minuto?


Imamo vrednost podatkov? Nimamo.

Ja. Pa ker je šef tako rekel.

Potem definitivno ne bi izbral MySQL, podatke bi pa še zmeraj prenašal s kupa na kup.

Invictus je izjavil:

Mavrik je izjavil:


A si ti pri svetovanju strankam tudi najprej neki zmisliš in potem začneš pizditi na osnovi te izmišljotine? Nikjer ni napisal da bere 100.000 odčitkov na minuto. Nikjer tudi ni napisal da lahko podatke kar tako zavrže in da so podatki sploh takšni da se karkoli da "povprečiti". Nekaj kar nekaj tumbat na pamet no.

Samo življenjske izkušnje ukvarjanja ravno s temi podatki. Raznimi monitoringi...

Stranke hočejo imeti neskončen arhiv, potem pa pizdijo, ko morajo dokupit diske. Arhivski podatki kar naenkrat postanejo nepomembni...



Slabo planiranje. Za arhiv se ve koliko približno bo stal v X letih, če imamo Y (količino podatkov). Se pa strinjam, da ŽIVLJENSKO POMEMBNI PODATKI hitro postanejo NIČ VREDNI PODATKi pri marsikateri stranki. Sploh ko čez 8 let rabi mail s priponko. Ampak ja, sej je podpisal izbris podatkov.

Zgodovina sprememb…

  • spremenil: MisterR ()

smacker ::

Invictus je izjavil:

Stranke hočejo imeti neskončen arhiv, potem pa pizdijo, ko morajo dokupit diske. Arhivski podatki kar naenkrat postanejo nepomembni...

+1: ko je treba za "arhiv" kupit 50TB dodatnega diskovja, se večina odloči da teh podatkov vseeno ne potrebuje več in se shranijo le statistike. Seveda pa za ustrezno svetovanje kaj naredit s podatki, rabimo več informacij, tak da OP še mora malo razložit, kaj počne s temi podatki in zakaj misli, da jih ne gre razkosat v več tabel.

Invictus ::

MisterR je izjavil:


Slabo planiranje. Za arhiv se ve koliko približno bo stal v X letih, če imamo Y (količino podatkov). Se pa strinjam, da ŽIVLJENSKO POMEMBNI PODATKI hitro postanejo NIČ VREDNI PODATKi pri marsikateri stranki. Sploh ko čez 8 let rabi mail s priponko. Ampak ja, sej je podpisal izbris podatkov.

Lahko mu daš izračun, pa ne pomaga... Pomaga šele, ko mora odpreti denarnico za nove diske :D.

Potem je čez 5 let o neki meritvi dovolj povprečna vrednost na dan...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

WarpedGone ::

podatke bi pa še zmeraj prenašal s kupa na kup.


Podatkov se ne prenaša ampak se začne delat nov kup, star kup pa zbriše, ko se politika odloči, da se ga ne potrebuje.
In to NI semantika ampak tehnični opis pravilnega postopka.

Žal je kopiranje+brisanje klasični pristop ...
Zbogom in hvala za vse ribe

Invictus ::

Na trenutnem projektu imamo zadevo lepo rešene na DB2 s particijami, ki vsebujejo dnevne podatke. Ko jih ne rabiš več, zbrišeš celo particijo.

Precej hitreje kot DELETE po bazi...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

krneki0001 ::

Najhitreje je unload na DB2. Narediš unload podatkov in jih spraviš v sekvenčno datoteko, potem pa reorg tabele. Podatke iz sekvenčne tabele pa potem lahko naloadaš v arhivsko tabelo ali pa kompresiraš datoteko in spraviš ali pa zavržeš.

Kroos ::

Očitno sem se kje malce narobe izrazil, tako da malce razjasnim zadeve:

Kar se tiče razbijanja / razkosanja podatkov, sem imel v mislih, da se te tabele ne da razbiti po stolpcih v več tabel (da bi zmanjšal row size), seveda pa je načeloma možno, da se arhivirajo npr. za leto 2015, 2014, ...
Ti podatki se uporabljajo za prikaz grafov in pa za prikaz histogramov. Pri histogramih je tako, da se te meritve poračunajo in ustrezno vpišejo v drugo tabelo, tako da podatkov prve tabele ne uporablja več, medtem ko za prikaz grafov pa se ti podatki še uporabljajo.

Zgodovina sprememb…

  • spremenilo: Kroos ()

krneki0001 ::

Potem naredi arhivsko tabelo in spravi notri podatke iz prejšnjih let. Grafe pa z bazo poveži tako, da gre za tekoče leto iskat v aktivno, za prejšnja leta pa v arhivsko tabelo.

Invictus ::

Pa res dobro razmisli kake grafe rabiš za leta nazaj...

Če jih seveda sploh rabiš ;).

Tukaj se da potem veliko prihranit.
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

MrStein ::

Kroos je izjavil:

Si bom kar to temo sposodil za svoje vprašanje, in sicer me zanima kako določiti maksimum vrstic / podatkov v neki MySQL tabeli?

Tule piše:

http://stackoverflow.com/a/2716470/8228...

The MyISAM storage engine supports 2^32 rows per table, but you can build MySQL with the --with-big-tables option to make it support up to 2^64 rows per table.

The InnoDB storage engine doesn't seem to have a limit on the number of rows, but it has a limit on table size of 64 terrabytes.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

SQL vprasanje (strani: 1 2 )

Oddelek: Programiranje		688402 (5081) BivšiUser2
»

[SQL] Unikatni izpisi

Oddelek: Programiranje		212236 (1623) 111111111111
»

SQL poizvedba

Oddelek: Programiranje		163282 (2627) awy
»

Pomoč pri zapisu php scripte

Oddelek: Izdelava spletišč		81232 (1074) technolog
»

MYSQL vprašanje

Oddelek: Programiranje		131809 (1424) MrBrdo

Več podobnih tem