zadnjih n redova

da li neko zna upiz za izvlacenje zadnjih n redova? Ja imam tabelu V koja mi sadrzi podatke od proizvodima i sad hocu zadnjih N da izvucem i da odstampam na stranu preko php-a.. tipovi koji su mi u tabeli su mi samo char i int i double.. jel moze pomoc? negde sam procitao da treba tip da bude auto_inrement ili kako se vec pise.. skoro sam poceo da radim u mysql i php-u uopste pa me zanmina kako da odradim ovo...

zadnjih po kom kriterijumu?

kriterijum "kada si ih insertovao u bazu" ne moze da se iskoristi posto ako to nisi upisao u slog - nemas pojma koji su slogovi "zadnji"

---

treba mi da izbaci po kriterijumu ime, zadnjih n redova unetih u bazu...

sta je kriterijum "ime" ?!



da li pamtis vreme za svaki slog kada je unesen u bazu?

---

pa znaci da po imenu izbaci zadnjih 10 redova a ime proizvoda je u koloni NAZIV.. nemam vreme nikakvo, tipovi podataka u tabeli su mi samo char, i jedna kolona enum("da", "ne") a trenutno u toj tabali imam 50redova...

i na osnovu cega mislis da baza zna koje si "upisao zadnje" ?

---

ahaam pa da, jbg :( a kako da resim to? Jel mi treba neka nova kolona ili kako sta?

ako hoces da ih sortiras po vremenu upisa onda dodas kolonu tipa datetime i pri upisu u nju stavis vrednost NOW() tako da se upise trenutno vreme. Onda kada radis select mozes da koristis ORDER BY topoljesadatumom DESC LIMIT 10

---

RADI! hvala puno!

Ovo bih radije resio sa auto_increment. Uglavnom je po nekom standardu prvo polje "id" i automatki se upisuje. Ako ga nema verovatno postoji "debeo" razlog zasto je tako.
Prednost je sto nece postojati dva upisa sa istim id. Naravno posto je auto_increment ne navodi se prilikom inserta.

na zalost auto increment je vrlo cesto POGRESNO upotrebljen za ovako nesto !!

auto increment ni po cemu ne daje sigurnost

- da ce brojevi da se povecavaju sekvencijalno
- da ce id-evi ici po redu unosa ..

dakle ako uradis iz 5 razlicitih klijenata na tabeli (create table t1 (id int auto increment not null primary key, x datetime) sledeci upit (insert into t1 values (null, now()) ladno moze da se desi da bude


1 2001-01-01 10:50:00
2 2001-01-01 10:50:10
3 2001-01-01 10:50:01
4 2001-01-01 10:50:07
5 2001-01-01 10:50:04

dakle - redosled auto increment polja NIJE UVEK isti kao redosled unosa .. posebno na ozbiljnijim storage enginima .. na primer za ndbcluster svaki sql nod kada radi upis u neku tabelu "rezervise" odredjen broj auto increment brojeva kako ih ne bi trazio svaki put za svaki unos, tu moze da se desi da imas bez problema id koji je 2 dana kasnije unesen od veceg auto inc id-a .. isto to rezervisanje auto inc vrednosti radi i innodb i mnogi drugi storage engine-i kao i mnoge druge baze podataka (ukljucujuci oracle, sybase, db2 ..)

dakle JEDINO sto auto increment GARANTUJE je UNIQUENESS - dakle da ces uvek da dobijes broj koji ne postoji, a i to samo ako ga nikad ne uneses u tabelu vrednost rucno, NE GARANTUJE NICIM NIKAKAV REDOSLED !!! ne garantuje da nema preskocenih vrednosti etc etc ..


isto tako, bilo koji select koji nema ORDER BY - NE GARANTUJE NIKAKAV REDOSLED ..


zakljucak - ako ti treba REDOSLED - MORAS DA IMAS POLJE PO KOME CES DA SORTIRAS KOJE CE TI OBEZBEDITI TAKAV REDOSLED

---

Ok, ok... nemoj samo da vices :))
Salim se naravno. Sad kada si objasnio kako to radi jasno je da najveci id nije sto posto poslednji upisan. Predpostvaljam da nisi mislio na varijantu kada se nesto upise pa se obrise i onda na njegovo mesto ponovo nesto unese.

Nego, to sto kazes desi se da je i 2 dana kasnije uneto to nesto sto se spremalo. Meni je bitno kada je poceo unos, tj. kada je id rezervisan a ne kada je unos okoncan.
AKo mozes da mi pojasnis kada tacno se rezervise/odredjuje id za nesto slicno sledecem:

Recimo da je proces poceo (kliknuto na "do" ili "insert") u 22:49:50, da je za obradu ovih podataka potrebno 20s, a samo upisivanje traje recimo 2sec. U koliko sati je rezervisan id i sta bi pisalo u polju vreme_unosa cija vrednost se odredjuje sa NOW() ?

ti NE ZNAS kada je ID REZERVISAN posto se ID ne rezervise samo u slucaju transakcije vec se rezervise kada to i kako to storage engine u kombinaciji sa hendlerom odradjuje. Na primer kada je ndbcluster u pitanju, auto_inc vrednost se rezervise kada se prvi put upisuje u tabelu koja ima auto_inc. Na primer sql nod rezervise 1024 id-a. To ne znaci da mu treba 1024 za tu transakciju .. samo znaci da je uzeo toliko, dakle tvoj slog sa ID-om iz tih 1024, rezervisan je juce, ali tvoja aplikacija je pozelela da upise slog danas tako da - ta dva podatka nisu ni u kakvoj relaciji ..

Cak i kada "ZNAS" kako se id rezervise (pogledas source pa vidis) - to nije "kvalitetna informacija" posto taj order / taj nacin alokacije id-a nije nicim zagarantovan i vec u sledecoj verziji / podverziji / bildu moze da se promeni te na to ne smes da se "oslonis"... sto je storage engine kao sam rdbms "pametniji" to manje stvari ovog tipa mozes da koristis posto optimizacije uveliko koriste ono sto "nije garantovano sql standardom" da bi ubrzale razne stvari...

primer .. (ne vezan direkno ali)


po kom ce redosledu ovaj select vratiti rezultat? pravilan odgovor je "nemam pojma". Kako SQL standard kaze da subquery ako nema limit order kojim vraca podatke je nebitan, prvo sto ce optimizer da uradi ovde je da izignorise order by A kompletno. Drugo - kako "glavni" (spoljni) select nema order by - opet, potpuno je nepoznato kojim redom ce da vrati rezultat sve i da je onaj subquery i bio sortiran... Zvuci nelogicno ali zamisli da imas proces koji cita fajl sa diska, mozes da citas fajl jednim tredom i citas ga od pocetka do kraja i to je neki "logican i najbrzi" nacin, ali zamisli da to radis sa 4 treda koji citaju fajl i pakuju podatke za slanje .. tada svaki tred cita 25% fajla sto znaci da ce podaci da se pakuju kao 1, 5, 9, 2, 6, 19, 3, 7, 11, 4, 8, 12, ... e sad zamisli da imas 20 tredova koji sluze za to i deljeni su medju upitima, pa ako imas 2 upita svakom zapadne po 10 tredova, ako imas 1 dobije svih 20 a ako imas 20 upita svaki dobije po samo jedan ... dakle bilo kakava racunica "kojim ce redom" nesto doci pada u vodu ...




zavisi od storage engine-a do storage engine-a, od verzije samog storage engine-a i od verzije mysql-a do verzije mysql-a i od dodatnih parametara ... i to samo ako gledamo mysql, ako gledamo dalje od mysql-a ...

recimo ako gledamo myisam - auto_increment je uzet onog trenutka kada se upisuje vrednost. MyISAM za razliku od ostalih tu nema neku pametnu logiku posto mu ne treba, kako radi sa table level lockingom uvek samo jedan thread pise po tabeli tako da on uzme auto_inc vrednost iz meta vrednosti tabele, upise je u slog, poveca meta vrednost za jedan i otkljuca tabelu ..

za innodb zavisno od verzije do verzije i od parametara u my.cnf ako transakcija ima 100 slogova rezervisace se 100 auto_inc vrednosti na pocetku transakcije (ako je mysql svestan da mu treba 100) ili ce se rezervisati jedan po jedan, u nekom slucaju ce interlocking transakcije da imaju interlocking id-eve a u nekom sekvencijalno grupe id-eva, nekad ce biti "po redu" a nekad nece. Dakle bez problema moze da ti se desi da unutar jedne transakcije id-evi ne idu po redu. Ali generalno kada je innodb u pitanju alokacija auto_inc-a ide na pocetku i tokom transakcije i po zavrsetku transakcije nema viska id-eva koji nisu iskoristeni (ovo ce mozda vrlo brzo da se promeni)

za ndbcluster na primer, sql nod rezervise od data noda broj auto increment vrednosti prvi put kada mu "zafali" auto_inc vrednost. Kolicina se setuje u my.cnf. Kada se transakcija zavrsi, neiskoristene vrednosti se cuvaju "za kasnije" tj za "kad zatrebaju" ili "dok se ne resetuje sql nod" - i nikada se ne vracaju nazad. Tako da sql nod moze da rezervise auto_inc vrednosti danas a da ih koristi narednih mesec dana (ako je na primer rezervisao 1000 komada a upisujes 10 slogova dnevno)

Pritom - ovo nista nije GARANTOVANO .. bez ikakve najave bilo sta od ovoga moze da se promeni, bas zato - auto increment vrednost ne sme da se koristi za bilo kakav "redosled" posto ona samim SQL standardom nikakav redosled ne garantuje.


da se vratim na pocetak - ako hoces da nesto sortiras po vremenu upisa, jedini nacin da to uradis pravilno je da upises vreme kada si ga upisao i sortiras po tom vremenu .. sve ostalo sto "skoro radi" nije garantovano da ce raditi u prvoj sledecoj verziji...

---

Zakomplikovao si.
Za ID ne znas koje ce vreme biti. A koje ce vreme biti za NOW() u slucaju koji sam naveo?

Da skratim. Autoru teme sigurno nece igrati ulogu par ms jer ceo proces nece trajati duze od 2 sekunde i verovatno ce postupak ponovo poceti kada se prethodni uveliko zavrsi. Sto opet znaci da se nece nista promeniti ni sam NOW().
Meni nije bitno kada se upis zavrsio. U tabeli gde imam polje vreme upisa definisao sam ga pri pocetku celog procesa tj. kada se prikupe podaci i pocne obrada. Kada ce se zavrsiti... sigurno u nekim situacijama jeste bitno ali nisam pricao o tome.

U svakom slucaju hvala na informacijama, korisne su. ;)

Pozzz

nije uopste komplikovano, samo je razlicito za svaki storage engine ... + moras da razmisljas o tome da li imas transakcije ili ne i sta se nalazi u jednoj transakciji ...

ako je cela transakcija taj jedan jedini upit onda je stvar prilicno jednostavna u vecini slucajeva (osim sa kompleksnim storage enginima kao sto su ndbcluster i ekipa). ako ne koristis transakcije (myisam, maria i ekipa) onda je jos jednostavnije ... ali ako koristis transakcije koje imaju vise od jednog statement-a onda stvar postaje komplikovana posebno sto imas transakcije koje se desavaju u paraleli, mnogo je redak slucaj da imas jedan tred koji izvrsava jedan insert i to je to ... u tom slucaju mozes da imas i txt fajl u koji apendujes txt ..

vreme za now ce biti vreme kada se upisuje taj slog ... sve ostalo (auto inc vrednost, etc) je vrlo razlicito i vezano za mnogo faktora, prvo od toga koji se storage engine koristi pa zatim od parametara, tacne situacije i slicno ...


to sto ce "slucajno" u "velikom broju slucajeva" auto inc da bude "po redu upisivanja" je SLUCAJNO a ne "pravilo" ... isto kao sto ce innodb u 99% slucajeva ako ne uradis order by da ti vrati slogove sortirane po pk-u .. to su sve SLUCAJNOSTI na koje ne smes da se oslanjas i uciti nekoga ko pocinje da koristi to kao resenje problema je pogresno ...

sto se mene tice, mozete da koristite i order by random() .. meni ni iz dzepa ni u dzep, samo - osvetice ti se kad tad ako se oslanjas na stvari koje su samo slucajno takve. Ja imam minimum jednom nedeljno klijenta koji kuka zasto mu aplikacija posle upgrade-a vise ne radi posto je on "probao i uvek mu je vracalo ovo a sada vraca ono" posto se oslanjao na "slucajne" stvari ...

el treba da ponovim - ako ti treba sortiranje po vremenu - sortiraj po vremenu i nemoj da se bavis pretpostavkama da ce nesto sto sada "slucajno" radi, raditi tako i "sutra"

---

Meni je sve jasno sto si napisao. Jos u startu. U pravu si. Radim sortiranje po vremenu kada mi je potrebno ali ja i dalje stojim iza toga da za autora teme order by id radi posao isto kao sa now. Kao da je sad milisekunda bitna a nije bitno kako ce trazeni proizvod da pronade ako nema id i postoje dva sa istim imenom. Nace ga nekako... valjda, ali prosto je nezamislivo nemati id u tabeli a on ga nema i posto mu definitvno moze da zavrsi order (pricam samo o njegovom slucaju) pametnije je da uvede id. Moze i vreme_unosa... ali u njegovom slucaju id je daleko funkcionalniji i potrebniji.
Kontam sta govoris i u pravu si, ali da bi to bilo znacajno za nas obicne smrtnike morali bi raditi daleko zesce stvari nego sto radimo.

Ne nije ti jasno.
Znam da je napisao puno teksta ali pročitaj sve, čovek zna šta priča, a ti očigledno ne znaš kad kažeš da ID radi posao isto kao datumsko polje.

---

A ti si sedeo samnom za kompom kada sam citao pa znas da li sam procitao ili nisam. Iscupao si iz konteksta moje reci i tvdis nesto sto nije tacno.
Govorim o ovom slucaju gde postoji pauzica izmedju unosenja proizvoda i gde ceo postupak unosenja traje delic sekunde pa je tako order by id isto kao i order by time. Visestruko je bitno da on uvede id, a ako mu je potrebno bas vreme kada je neki proizvod unet onda da uvede vreme_unosa.

Znam da Bogdan zna o cemu govori, vidi se kroz njegove postove i na drugim temema da poseduje zavidan nivo znanja. Krivo mi je sto sam se upustio u diskusiju jer ispadne da ja njemu pametujem a to mi nije namera. Ja samo branim svoj stav vezan za ovaj slucaj o kom autor teme prica. Order by id u ovom slucaju ce dati isto kao i order by time.

@bogdan
Hvala jos jednom za korisne informacije. Treba raditi kao sto savetujes. Ali pametnije je uvesti id nego time (u ovom slucaju), ili i jedno i grugo.

osnovna stvar u kojoj gresis je bas to sto savetujes pocetniku da koristi auto_inc ... ne u tome da "to nece da radi" .. .

kada si ucio da vozis, da li ti je instruktor rekao kada zatreperi zeleno da usporis i stanes na zuto koje dolazi, ili da das gas i prodjes kroz zuto? Naravno da ti je rekao da usporis i stanes na zuto!!! E sad, to sto ti posle 10K kilometara mozes da doneses odluku da ces u istoj situaciji da dodas gas i prodjes kroz zuto - to je tvoja odluka bazirana na 10K kilometara gde si ti svestan rizika koje ta odluka donosi a isto tako znas da je po ps-u da usporis i stanes. Isto tako, da, op-u ce 99% da odradi posao auto_inc, ali zasto ga u startu uciti pogresno. U startu treba da zna kako se to radi pravilno, a kad utrosi par iljada covek sati u rad sa bazama nece mu trebati ni moja ni tvoja pomoc da se odluci da li ce koristiti auto_inc ili polje sa datumom....

ja kapiram da bi mlade generacije odma gas pa kroz crveno, al aj prvo naucite kako treba, pa posle ako ocete da se ubijate, slobodno to cinite (po mogustvu ne ispod mog prozora posto mi zao da gledam kako svako drugo vece natacinjete skupa kola na jeftinu banderu, budite momke iz hitne ..)

---

Svasta s tobom... prvo zakomplikujes a onda banalizujes i koristis primer(?!) da mene smestis u neku mladu generaciju... Nisam iskusan i nemam znanja kao ti i nije frka da to kazem (nemam nameru da ispadnem tamo neki pametni baja), ali zaboga mi diskutujemo o krajnje jednostavnoj stvari, prvoj liniji sa kojom se neko sretne kada pocne koristiti bazu.

Ja mu savetujem da koristi ID zbog lakseg pronalazenja proizvoda u bazi. A ako ce da radi posao order by id, neka radi... slozio sam se s tobom da je preciznije sa time.

Vise stvarno ne vidim u cemu je problem i cemu dalja diskusija. Pogotovo crveno, zuto svetlo i voznja automobilom ispod tvog prozora(?!) - izvini ali to je skolski primer trolovanja.

Razumeli smo se tj. bar sam ja tebe razumeo. :)

Pozz ;)

_{[Ovu poruku je menjao masinac_1 dana 03.06.2010. u 21:55 GMT+1]}