|
Po 1 najnovija iz svake kategorije
Mozgalica? (za nekoga mozda nije):
imam kategorije i vesti. Treba jednim querijem da izvucem po jednu najsveziju vest iz SVAKE kategorije, znaci ako imam vesti: kat1 vest1, kat1 vest2 kat2 vest1, kat3 vest1 kat4 vest1, kat4 vest2, kat4 vest3 Da kazemo da je poslednja najsvezija, treba da dobijem (jednim querijem) kat1 vest2 kat2 vest1 kat3 vest1 kat4 vest3 Znaci nije frka dobiti najsvezije ali mi treba tacno po 1 najsvezija iz svake kategorije (jednim querijem). Moja prva ideja je da probam sa: group BY cat_id ORDER BY news_date DESC iskreno jos nisam ni probao, hocu prvo na forum ... :) Ideje? |
Da li su dozvoljeni subselectovi?
|
I guess :) ali to nije onda 1 query :) salim se, shoot.
|
Kôd:
SELECT DISTINCT kat, (SELECT vest |
Nemam mysql 5 i ne radi mi tako, ali radi ovako:
SELECT news_id, cat_id from news group by cat_id order by news_date DESC; Dobijem: Kôd:
+---------+---------+ |
Super. Ja sam koristio logiku iz MSSQL-a, u kome inače ne možeš da staviš među rezultate (a ni među ORDER BY parametre) kolonu koju nisi stavio u GROUP BY.
|
Trebalo bi da radi i:
SELECT MAX(news_id) AS max_id, cat_id from news group by cat_id ORDER BY max_id DESC; |
jel u mysql sa autoincrementom na id koloni garantovano da je noviji ID uvek veci od starijeg? Ili se re use-uju obrisani id-ji ? I sta se desi kad se iskoriste svi raspolozivi id-ji, jel krene opet od 1?
samo pitam, mrzi me da trazim po dokumentaciji :) |
novi id je uvek veci za jedan od poslednjeg generisanog. to lako mozes proveriti ako uradis DELETE FROM `table` i ubacis novi zapis. resetovanje countera postizes jedino pomocu TRUNCATE TABLE `table` komande.
Uzgred, ako dostignes max broj zapisa u jednoj tabeli, verovatno neces zeleti da koristis mysql, cija stabilnost i brzina se inace dovode u pitanje kada tabela sadrzi vise od par desetina miliona zapisa... |
Garantovano je osim ako ne radis rucno update, sto nisam jos cuo da neko radi.
Ako imas ovako 1 2 3 4 5 6 i onda obrises 4, sledeci record koji dodajes je 7, znaci imas 1 2 3 5 6 7 E sad, ako si dovoljno lood pa napravis da umesto novog recorda dodas bas na mesto 4, sto je moguce, onda moze da se desi da je manji ID noviji od najveceg. Ali kao sto rekoh, to niko normalan ne radi, jer bi onda morao da cuvas informacije o obrisanim ili pre svakog unosa da pretrazis bazu, koji je obrisan. To se nekada radilo sa binarnim stablima, kada se obrise record, one se obicno nije fizicki brisao nego se markirao flag da je obrisan, a u headeru tabele se cuvao offset tog recorda. Kada bi se dodavao sledeci, citala bi se informacija iz headera i file pointer pomerio na taj offset za upis. Na tom mestu je bio sacuvan offset prethodnog obrisanog recorda koji bi se onda upisao u header kao sledeci "slobodan". Znaci, svaki obrisani record je cuvao offset prethodno obrisanog. Ako nema, onda se belezi EOF kao znak da se sledeci record upisuje na kraj fajla. To je meni bila jednostavna ali interesanta filozofija. Nekada nisu postojali ogromni hard diskovi i moralo se voditi racuna o svakom bajtu prostora. Zato je meni i danas cudno kada vidim da neko deklarise sva char polja u tabeli kao VARCHAR(255), a generalno je sve jedno. Mysql ionako ima svoju optimizaciju za manje od 10 a za ove vece, sve jedno je da li je varchar(35) ili varchar(255), razlika je u jednom bajtu. Jedino sto je malo sporije indeksiranje, ali generalno nema veze. Ma secam se nekada da su se podaci pakovali u bitove, sada to samo zaludni rade :) Eto, malo iskustva, kada sam ja proucavao i cak pravio neke ovakve stvari, mislim da jos uvek mogu da pronadjem kompletan BTree source koji sam pravio u C-u :) |
| Vreme je GMT +2. Trenutno vreme je 01:51. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.