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 :) |
Citat:
|
Na to nisam obratio paznju :) Svakako, lepo je da postoji i alternativa..
|
ma samo pitam jer nikad nisam o tome nesto razmisljao, obicno uvek stavim timestamp kolonu kad treba nesto vremenski sortirati, jer mi to pomaze i kod posmatranja rada skripte (prikazi sve rekorde od danas i slicno), pa nije bilo ni potrebe da znam kako se tacno generise autoincrement sekvenca...
@zextra: u pravu si za max broj recorda, po mom iskustvu posle 4 miliona recorda myISAM tabele se jako uspore, ali ne zaboravi da ti mozes i da brises recorde, a da se kao sto smo zakljucili ID-jevi ne resetuju. Znaci uzmi u obzir recimo active_sessions tabelu na jako posecenom sajtu gde se dnevno zapise i obrise recimo 100K ili vise novih recorda. Vrlo brze ces da prefuras 2^32... |
Da, jasno. Samo, pod predpostavkom da se radi o active_sessions tabeli, ne vidim zasto bi ti primary key polje bio auto_increment - najcesce sesije vodis po nekom hashu, koji u ovom slucaju moze da bude primarni kljuc - bitno je samo da vodis racuna da generises unique hash (recimo, md5 od remote ip + microtime, prilikom logovanja), a obzirom na to da u pomenutoj tabeli cuvas samo aktivne sesije (koja cuva samo korisnike koji su bili aktivni u poslednjih x minuta), tesko da ces imati preko 10,000 aktivnih korisnika u isto vreme :) Ako budes imao, onda se verovatno neces ni zamajavati sa mysql-om.
Pricam samo hipoteticki, naravno, uvek se moze naci neko kome ce ustrebati +inf za auto_increment. |
Tema se na neki način nastavila u jednoj od tema na ES-u, korisnik chacka je dao još par alternativnih upita za MSSQL, jedan bez subselecta...
http://www.elitesecurity.org/t199541...pit-GRUP-BY-sl |
Vreme je GMT +2. Trenutno vreme je 05:28. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.