DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > SQL baze podataka - Sponzor: Baze-Podataka.net
Beach Wedding Dresses - Looking for the Wedding Dress? Here, 1dress.co.uk stunning collection of beach wedding dresses is just what you are looking for.
charles wang

SQL baze podataka - Sponzor: Baze-Podataka.net MySQL, MSSQL, Oracle, Access, ODBC. Ako imate problem brže i preciznije ćete dobiti odgovor ako priložite strukturu tabela ili skript koji kreira tabele i puni ih test podacima umesto što to problem opisujete samo rečima. Sponzor: Baze-Podataka.net - Blog o bazama podataka

Odgovori
 
Alati teme Način prikaza
Staro 25. 08. 2007.   #11
sasas
novi član
Na probnom radu
 
Datum učlanjenja: 20.08.2005
Poruke: 13
Hvala: 0
0 "Hvala" u 0 poruka
sasas is on a distinguished road
Default

Citat:
Originalno napisao bluesman Pogledajte poruku
Eto, tacno to, pravi skolski primer, prvi na koji naidjes kada citas knjigu
Jok, ja sam knjiga (a marfi je čudo) Sve je stvar nekakvog trejd-ofa, kao što rekoh treba meriti - ja bih na primer uvek išao i na taj delić promila da se (ma koliko nepotrebno) zaštitim radije nego da dobijem koji promil u brzini. Ali definitivno bi presudilo to da je left join == manje programiranja za isti rezultat, ne možeš poreći da nam teorija ovaj put skraćuje posao

pozz
sasas je offline   Odgovorite uz citat
Staro 25. 08. 2007.   #12
Petar Marić
Python Ambassador
Master
 
Avatar Petar Marić
 
Datum učlanjenja: 06.06.2005
Lokacija: Novi Sad
Poruke: 602
Hvala: 28
27 "Hvala" u 17 poruka
Petar Marić će postati "faca" uskoro
Pošaljite ICQ poruku za Petar Marić
Exclamation

Citat:
Originalno napisao bluesman Pogledajte poruku
Sto volite da komplikujete stvari, strasno... samo da bude knjiski - bez obzira sto se radi 3 subselect-a i sto ce taj query da se vuce za sve sto ima preko 100 recorda.
Heh, izgleda da se nismo razumeli - rešenje koje mi se najviše sviđa je:
Kôd:
SELECT * FROM Tasks
LEFT JOIN ass ON
  Tasks.Id = ass.id_task
WHERE
  ass.id_user = {{USER_ID}} OR
  ass.id_user IS NULL
I u njemu ne vidim podupite. Ovakvo rešenje je verovatno dovoljno dobro za najveći broj situacija, inače ne bi bilo preporučeno i ne bi ušlo u knjige.

Citat:
Originalno napisao bluesman Pogledajte poruku
Ali mi razmisljamo drugacije, vi razmisljate "by the book" (zato sam i rekao ono gore) a ja razmisljam odmah o sajtu gde ima 50 000 clanova i u svakom trenutku bar 500 online. Ovde je situacija negde blize vasem slucaju, ali se najezim kada vidim da pored jednostavnog resenja neko preferira subselect-ove
Prvo, čini mi se da je primer promašen pošto (koliko znam) Ilija pravi aplikaciju za upravljanje projektima, a ne forum. Što bi jedan moj prijatelj rekao babe/žabe sindrom

Drugo, verujem da si čuo za izreku "premature optimization is the root of all evil". Daleko od toga da ne treba misliti o njoj u fazama projektovanja i implementacije, ali da razmišljamo samo o sirovoj brzini dan-danas bismo programirali u asembleru (u najboljem slučaju).

Treće, ne vidim kako ti je jednostavnije da sam brineš o integritetu podataka pored mehanizama koje ti sam sistem pruža.

Citat:
Originalno napisao bluesman Pogledajte poruku
Pored toga, mysql po defaultu konvertuje OUTER joinove u dva JOIN-a, tako da to sto vama izgleda "semanticki lepo" i mozes za rever da okacis u stvari je pravi mali genocid za mysql server.
Hm, za ovo ne znam i nisam našao na netu - ali ako je tvoja tvrdnja tačna malo mi je čudno da se upravo MySQL preporučuje za OLAP sisteme koji rukuju ogromnom količinom podataka koristeći join-ove sa nemalim brojem uslova za spajanje.


U zaključku - uvek sam za jednostavna rešenja koja provereno rade a od mene zahtevaju minimalna ulaganja. Tek ako nastane problem analiziram ga, biram osobine za poređenje, optimizujem (refaktorišem ili menjam rešenje), merim osobine, poredim dobijene rezultate, i na kraju donosim odluku.

Nemogućnost merenja osobina, a samim tim poređenja rezultata svodi optimizaciju na čistu masturbaciju - radiš nešto čija je korist u najmanju ruku (excuse the pun) diskutabilna.
__________________
Python Ambassador of Serbia
Petar Marić je offline   Odgovorite uz citat
Staro 26. 08. 2007.   #13
bluesman
Goran Pilipović
Sir Write-a-Lot
 
Avatar bluesman
 
Datum učlanjenja: 18.05.2005
Lokacija: Beograd
Poruke: 5.450
Hvala: 288
1.238 "Hvala" u 446 poruka
bluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušatibluesman je osoba koju treba slušati
Pošaljite ICQ poruku za bluesman
Default

Ja sam komentarisao predlog:

SELECT * FROM Tasks WHERE Id IN (SELECT id_task FROM ass WHERE id_user = 1) OR Id NOT IN (SELECT id_task FROM ass)

Nadam se da vidis subquerije ovde gore ^. Po meni - jako lose resenje.

Da se ne nastavljamo, potrazi na netu, a mozes i u mysql manualy, odeljak optimization, kako se outer joinovi konvertuju u seriju inner joinova. Ja ne kazem da se ne koristi outer join, vec da se koristi kada ima potrebe za to. Ali opet, sta ja znam o tome? ... radi kako hoces
__________________
Goran Pilipović a.k.a. Ugly Fingers Bradley f.k.a. bluesman
I don't always know what I'm talking about but I know I'm right!
bluesman je offline   Odgovorite uz citat
Staro 26. 08. 2007.   #14
Petar Marić
Python Ambassador
Master
 
Avatar Petar Marić
 
Datum učlanjenja: 06.06.2005
Lokacija: Novi Sad
Poruke: 602
Hvala: 28
27 "Hvala" u 17 poruka
Petar Marić će postati "faca" uskoro
Pošaljite ICQ poruku za Petar Marić
Cool

Citat:
Originalno napisao bluesman Pogledajte poruku
Ja sam komentarisao predlog:

SELECT * FROM Tasks WHERE Id IN (SELECT id_task FROM ass WHERE id_user = 1) OR Id NOT IN (SELECT id_task FROM ass)

Nadam se da vidis subquerije ovde gore ^. Po meni - jako lose resenje.
Slažem se da je to lošije rešenje, ipak je bila greška u komunikaciji - izgleda da si mislio da podržavamo podupite umesto left join-ova - as if

Citat:
Originalno napisao bluesman Pogledajte poruku
Da se ne nastavljamo, potrazi na netu, a mozes i u mysql manualy, odeljak optimization, kako se outer joinovi konvertuju u seriju inner joinova. Ja ne kazem da se ne koristi outer join, vec da se koristi kada ima potrebe za to. Ali opet, sta ja znam o tome? ... radi kako hoces
Obavezno ću pogledati sutra, kad budem odmorniji
Čisto da znam - jel ta pojava još postoji u 5.x verziji ili samo u 4.x?
__________________
Python Ambassador of Serbia
Petar Marić je offline   Odgovorite uz citat
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum

Slične teme
Tema Početna poruka teme Forum Odgovori Poslednja poruka
'multiple' ispis iz baze eclipse Sva početnička pitanja 13 16. 12. 2010. 01:26
Programeri vs Korisnici bluesman Programiranje 35 21. 03. 2010. 19:56
Huawei HG510 Multiple Vulnerabilities Ivan Opušteno 4 18. 02. 2010. 22:59
[REŠENO] multiple image upload? dootzky Web aplikacije, web servisi i software 6 03. 10. 2007. 14:35
vTiger CRM Multiple Vulnerabilities Ivan Opušteno 0 04. 09. 2006. 13:58


Vreme je GMT +2. Trenutno vreme je 11:11.


Blogodak - Domaci blogovi na jednom mestu Caught in a web - web dev blog
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.