[ wRong @ 12.05.2004. 12:54 ] @
Pozdrav ,
treba mi mala pomoc oko izrade mysql baze podataka.
Baza treba da sadrzi 1000-10.000 razlicitih proizvoda a svaki proizvod ima nekoliko kategorija i podkategorija kojima pripada.
Mislio sam da za sve kategorije i podkategorije napravim posebnu tabelu a u glavnoj tabeli da cuvam njihov id ali je problem sto bi u jednom polju morao da drzim nekoliko id za svaku kategoriju i podkategoriju sto mislim da nije dobro resenje.Treba da napomenem da postoji i mogucnost dodavanja novih kategorija i podkategorija.
Nadam se nekom brzom odgovoru posto mi je prilicno hitno.

wRong
[ noviKorisnik @ 12.05.2004. 13:06 ] @
To ti je relacija više prema više. Kreira se tabela koja spaja tabele proizvoda i kategorija.

Pripada (id_proizvoda, id_kategorije)
[ broker @ 12.05.2004. 13:07 ] @
Uzmimo jednostavan slucaj gde svaki proizvod moze da bude u vise kategorija

Trbaju ti tri tabele: tablea kategorija, tablea proizvoda i table koja povezuje proizvode sa kategrijama


KATEGORIJE

ID_KATEGORIJE
NAZIV


PROIZVODI

ID_PROIZOVDA
NAZIV


KAT_PRIOIZV

ID_KATEGORIJE, ID_PROIZVODA

Sada za svaki proizvod u KAT_PROIZV stais slog za kategoriju kojoj pripada, koliko kategorija, toliko proizvoda.

Kada uvedes podkategorije to unekoliko komplikuje stvar ali je princip isti.
[ Dejan Topalovic @ 12.05.2004. 13:28 ] @
Ja bih to napravio ovako:
- kreiras 3 tabele:
1. tabela_proizvodi
id_pro
... ostala polja za proizvod ...

2. tabela_kategorije
id_kat
id_subkat
... ostala polja za kategoriju ...

U id_subkat stavljas id_kat one kategorije kojoj je ta kategorija podkategorija.
Npr. id_kat = 1 je za kategoriju "Kategorija1". Ako kreiras neku podkategoriju npr. "podkategorija1", onda ces staviti id_kat = 2, id_subkat = 1 . Ako se radi o kategoriji, onda je njen id_subkat NULL .
Valjda je jasno ... Ili da objasnim jos detaljnije ?

3. tabela_lookup
id_za_proizvod
id_za_kategoriju

To stavis sve u PRIMARY KEY. Npr. imaces kombinaciju (id_za_proizvod, id_za_kategoriju)


Dala bi se izvesti kombinacija i sa razdvajanjem kategorija od podkategorija, ali onda bi se zakomplikovalo sve pri sklapanju odgovarajuceg SELECT upita ili neke druge operacije (UPDATE, DELETE, INSERT).
[ wRong @ 12.05.2004. 16:36 ] @
Ok,
jasno mi je kako da povezem kategorije i pod kategorije,
ali problem je sto jedan proizvod moze da spada pod nekoliko kategorija i nekoliko pod kategorija,sto znaci da bi na 1000 proizvoda ako proiz. ima 4 kat i 14 pod kat. imao 56000 kombinacija u tabeli look_up ,a na 10.000 proizvoda 600.000 kombinacija???
[ Dejan Topalovic @ 12.05.2004. 17:20 ] @
Pa, ako imas 4 kategorije sa 14 podkategorija u svakoj, onda je to otprilike taj iznos koji si naveo.
Mozes ti da izvedes da kategorije i podkategorije cuvas samo u jednoj koloni, a da su te vrijednosti medjusobno odvojene nekim proizvoljnim delimiterom, npr. %% ili :: . Medjutim, onda moras da vrsis naknadne operacije da bi izvukao odredjenu zeljenu vrijednost za pojedinu kategoriju ili kategoriju kojoj proizvod pripada.

Vidi kako ti je lakse i efikasnije, pa optimizuj po svojoj potrebi.
[ wRong @ 12.05.2004. 18:21 ] @
Citat:
Vidi kako ti je lakse i efikasnije, pa optimizuj po svojoj potrebi

pa lakse mi je da ubacim nekoliko vrednosti u jednu kolonu ali ne znam kako je efikasnije
[ Gojko Vujovic @ 12.05.2004. 18:24 ] @
Čuvanjem više takvih vrednosti u istoj koloni baza gubi smisao. Što onda ne bi sve držao u jednom txt fajlu ako će ručno da parsira i pazi o storage-u? Tri tabele pod obavezno, a ne znam što te brine broj kombinacija, to su mala polja, indeksi će raditi posao i ni 600.000 redova neće zauzeti mnogo vremena ili značajno usporiti query. Možeš i da obaviš testiranje sa kverijima koje planiraš i vidiš koliko je sve optimizovano pre nego što se odlučiš za neko rešenje.
[ wRong @ 12.05.2004. 19:28 ] @
Citat:
Možeš i da obaviš testiranje sa kverijima koje planiraš i vidiš koliko je sve optimizovano pre nego što se odlučiš za neko rešenje.


to bi voleo da testiram ali kako da simuliram 1000 proizvoda u bazi???


Citat:
Tri tabele pod obavezno, a ne znam što te brine broj kombinacija, to su mala polja, indeksi će raditi posao i ni 600.000 redova neće zauzeti mnogo vremena ili značajno usporiti query.


pa nemam puno iskustva pa zato i pitam znaci mislis da je to ok resenje?


imam problem i sa cenom,ne znam koliko da trazim za izradu jedne ovakve baze ima tu jos dodatnih zezalica ovo je samo jedan deo.Koliko naplacujete takve stvari,mada znam da je ovo tabu tema ali ajde mozda mi neko kaze
:)
[ noviKorisnik @ 12.05.2004. 20:10 ] @
Citat:
wRong:
Ok,
jasno mi je kako da povezem kategorije i pod kategorije,
ali problem je sto jedan proizvod moze da spada pod nekoliko kategorija i nekoliko pod kategorija,sto znaci da bi na 1000 proizvoda ako proiz. ima 4 kat i 14 pod kat. imao 56000 kombinacija u tabeli look_up ,a na 10.000 proizvoda 600.000 kombinacija???

Ne razumem se baš tako u tu matematiku - kako dobijaš 56000 kombinacija?

Za svaki proizvod imaš tačno onoliko zapisa u tabeli look_up koliki je broj kategorija i potkategorija kojima taj proizvod pripada. Ako se - prema tvom primeru - svaki proizvod nalazi u 4 kategorije i 14 potkategorija, i ako ima 1000 takvih proizvoda - to mu dođe ukupno 18000 zapisa u tabeli look_up.

I obrati pažnju da su potkategorije u stvari kategorije tako da možeš da ih zanemariš pri analizi.
[ _owl_ @ 12.05.2004. 20:36 ] @
Bez obzira na broj proizvoda (ili mogucih kombinacija) nikako ne bi smeo da narusavas 1NF pogotovo u tabeli koja spaja proizvode i kategorije. Nad tabelom ces ionako da dignes indeks koji ce znatno ubrzati izvrsenje upita u odnosu na drugo resenje (sa narusenom 1NF). Samo treba malo razmisiliti o nacinu pretrage kada je narusena 1NF i takvo resenje odmah odbaciti.
@Stripy
Ti imas polozen neki od Oracle sertifikata?? (i mozes da mu predlozis takvo resenje)
[ Gojko Vujovic @ 12.05.2004. 20:40 ] @
MISLIM da to nije mnogo i da se neće ni osetiti, ali nemoj da se oslanjaš na naša mišljenja već sam testiraj pošto dosta faktora utiče na krajnje performanse - opterećenje servera u datom trenutku, optimizovanost servera i količina dostupnog rama, dobro planirani indeksi, dobro planirani kveriji (takvi da ih mysql može optimizovati, imaš na sajtu šta on zna da optimizuje u upitu a šta ne), itd.

Napravi scriptu koja će dodati 100000 proizvoda i smestiti ih u odgovarajuće kategorije u loopu. Imena mogu isto biti generisana jer nisu bitni pravi nazivi za ishod testiranja. Pisanje takve scripte ne oduzima obično više od 10-15 minuta.
[ Dejan Topalovic @ 12.05.2004. 20:43 ] @
@_owl_: Naravno da sam protiv tog drugog rjesenja. To sam naveo onako samo kao neko eventualno rjesenje, ako je covjeku tako lakse (mada znam da nije ). Sta ja znam kako je on zamislio strukturu razvoja svega ovoga i na koji nacin misli da obradjuje podatke iz baze.
Nisam mu izricito naredio:"Moras da koristis to drugo rjesenje!"

Dakle, konacan zakljucak bi bio da uradi onako sa tri tabele kao sto smo mu rekli.
Sto se tice cijene, to je varijabilno i diskutabilno pitanje. Ako radis ovo sa PHP-om, onda za ovaj dio projekta u koji spadaju projektovanje strukture baze i izrada PHP skripti, mozes uzeti 200-300 evra. Za neke druge stvari dodaj iznos u zavisnosti koliko je ulozeno vremena u to.
[ wRong @ 13.05.2004. 15:26 ] @
Citat:
Ne razumem se baš tako u tu matematiku - kako dobijaš 56000 kombinacija?

ni meni matematika nije jaca strana :)
1+1=0
Citat:
Napravi scriptu koja će dodati 100000 proizvoda i smestiti ih u odgovarajuće kategorije u loopu. Imena mogu isto biti generisana jer nisu bitni pravi nazivi za ishod testiranja. Pisanje takve scripte ne oduzima obično više od 10-15 minuta.


to cu i da uradim

[ NetworkAdmin @ 13.05.2004. 22:04 ] @
Evo kako to ja uradim:

Code:
CREATE TABLE `products` (
  `productid` int(11) NOT NULL auto_increment,
.....
.....
.....
.....
  `categoryid` int(11) NOT NULL default '0',
  `categoryid1` int(11) NOT NULL default '0',
  `categoryid2` int(11) NOT NULL default '0',
  `categoryid3` int(11) NOT NULL default '0',
......
......
......

  `forsale` char(1) NOT NULL default 'Y',
.....
  PRIMARY KEY  (`productid`),
......
  KEY `categoryid1` (`categoryid1`,`categoryid2`,`categoryid3`),
  KEY `category` (`categoryid`),
.......
.......
.......
......
  KEY `categories` (`forsale`,`categoryid`,`categoryid1`,`categoryid2`,`categoryid3`)
) ENGINE=MyISAM; 
[ bluesman @ 14.05.2004. 11:10 ] @
Zašto tako "networče-admine" ? :-)
[ Dejan Topalovic @ 14.05.2004. 11:23 ] @
Da, zasto tako? Mozes li objasniti svoj princip strukturisanja te tabele u bazi?
[ Gojko Vujovic @ 14.05.2004. 11:26 ] @
NetworkAdmine tako krsis pravila normalizacije o kojima smo pricali. I bas da vidim kako ces da dodas proizvod u vise od 4 kategorije? Znamo da je dodavanje kolona 'skuplje' po svakom pitanju od dodavanja novih redova.
[ broker @ 14.05.2004. 13:39 ] @
Ako je pred aplikacijom takav zahtev da ne treba vise od 4 kategorije, onda ovo ima smisla, narocito za web aplikacije, jer se time stvari dosta pojednostavljuju (web korisnicki interfejs se uproscava).
[ bluesman @ 14.05.2004. 13:53 ] @
Ovo je sve samo nije pojednostavljenje.

Pedja, ne znam samo kakve veze ima "web korisnicki interfejs" odnosno njegovo "uproscavanje" sa ovim, a narocito zasto je ovako "prostije"?
[ Gojko Vujovic @ 14.05.2004. 14:31 ] @
Interfejs ostaje isti a kveri je normalizovaniji zajedno sa bazom.
[ Dejan Topalovic @ 14.05.2004. 16:20 ] @
Citat:
broker:
Ako je pred aplikacijom takav zahtev da ne treba vise od 4 kategorije, onda ovo ima smisla, narocito za web aplikacije, jer se time stvari dosta pojednostavljuju (web korisnicki interfejs se uproscava).

Sta ako nakon 3 mjeseca dodje do potrebe da se doda jos jedna kategorija? Da li je lakse dodati jedan red u tabeli ili kreirati u bazi jos jedno polje za tu kategoriju?

Projektovanje baze nema veze sa uproscavanjem web interfejsa. Ti mozes imati 100 polja u tabeli, ali samo da ih 10 prikazujes na sajtu. Ili recimo da imas samo 10 polja u tabeli, a prikazujes kompleksne kombinacije, summaries ili bilo koje djidje-midje zasnovane na samo tih 10 polja.

Ovo gore je primjer jednog customized rjesenja na principu "uradi i ne diraj vise nikad". Medjutim, u vecini slucajeva se pokaze potreba za prosirivanjem ili nekim drugim vidom izmjene odredjene aplikacije, a samim tim i strukture baze.
[ NetworkAdmin @ 16.05.2004. 23:39 ] @
meni jos nikad nisu trebale vise od 4 kategorije a ako treba jos koja odradim alter table... ne pravim ebuy a ovo radi svoj posao... vidio sam shopove sa ovom tabelom od jedno 4000 produkata ljudi nikad nisu trazili dodatne kategorije.
[ NetworkAdmin @ 16.05.2004. 23:48 ] @
E da samo vidim ovdje ima malo zabune.

Broj kategorija je neogranicen ali samo jedan product moze biti u 4 kategorije maksimalno to je to.

Sad zasto ovako... mozemo mi filozofirati koliko hocemo ova tabela je nastala u razvoju prvo je bio product, category pa kad se pojavila potreba za secundary category dodali smo i theerd i forth category umjesto da pravimo tabelu productid categoryid koji bi vezao te kljuceve...

Broker je dobro naglasio, queries ostaju isti... to je trebalo odraditi jedne vecere bukvalno i sad da nebi pravili zesce izmjene na web interface, modifikovali smo product i kod definisanja kategorija se moze dinamickidodavati primarna i tri alternativne kategorije.

Zora svice dan se bjeli i mi isporucili modifikovan shop i sve OK. To je naravno uslo u sledeci release kao new feature i zivi svoj zivot sasvim dobro.

U zivotu je bitno se snaci i zadovoljiti funkciju... ovo radi... svi sretni i veseli :)
[ broker @ 17.05.2004. 00:49 ] @
Citat:
bluesman

Pedja, ne znam samo kakve veze ima "web korisnicki interfejs" odnosno njegovo "uproscavanje" sa ovim, a narocito zasto je ovako "prostije"?


Ima veze, napraviti interfejs za unosenje sloga koji ima cetiri lookup poljaje prosta stvar, a napraviti interfejs koji omogucava da se unose podaci u tabele vezane u 1-n relaciju nije bas tako mali posao. Ko tvrdi drugacije slobodno nek mi da link na nesto sto je jednostavno, UNIVERZALNO, i radi taj posao kako treba.

Citat:
StRiPy
Sta ako nakon 3 mjeseca dodje do potrebe da se doda jos jedna kategorija? Da li je lakse dodati jedan red u tabeli ili kreirati u bazi jos jedno polje za tu kategoriju?


Pricamo o konacnom resenju. Imao sam u mnogo navrata priliku da radim modeliranje baza u kojima su bili bas takvi zahtevi, konacan broj lukap veza ka nekoj tabeli.
Milsim da je sasvim logicno da kada diskutujemo uvek podrazumevamojasno definisan zadatak, dobro projektovan sistem i da nema sta bi bilo kad bi bilo.

Citat:
NetworkAdmin
Broj kategorija je neogranicen ali samo jedan product moze biti u 4 kategorije maksimalno to je to.


Tako sam i razumeo.

Citat:

Sad zasto ovako... mozemo mi filozofirati koliko hocemo ova tabela je nastala u razvoju prvo je bio product, category pa kad se pojavila potreba za secundary category dodali smo i theerd i forth category umjesto da pravimo tabelu productid categoryid koji bi vezao te kljuceve...


Ovde ste pogresili. Onog momenta kada je predocena mogucnost da treba da postoje dve lukap veze ka drugoj tabeli, moras postaviti pitanje da li je moguce da treba i vise i ako je odgovor potvrdan to je automatski 1-n veza, bez obzira da li je to trenutno neophodno. Sustina dobrog projektovanja je u uopstavanju - uocavanju konkretnih slucajeva koji se mogu svesti na opstiji slucaj.

Citat:

U zivotu je bitno se snaci i zadovoljiti funkciju... ovo radi... svi sretni i veseli :)


Apsolutno se ne slazem sa ovakvim pristupom. Ispadne to uvek po onoj staroj: ko ne plati na mostu, platice na cupriji. Srz svake baze podataka je model. On mora da se radi skolski postujuci sva nacela. Svako odstupanje od nacela mora da bude opravdano jakim razlozima medju kojima ne moze da bude: ovako je brze napraviti i radi posao, svi sretni i zadovoljni.

Prihvatam da nekada sama aplikacija mora da vadi fleke zbog nedostataka platforme (ko radi u MySQL-u sigurno zna na sta mislim) ali nikako da vadi fleke zbog lose projektovanog modela.
[ bluesman @ 17.05.2004. 01:21 ] @
Citat:

Citat:

U zivotu je bitno se snaci i zadovoljiti funkciju... ovo radi... svi sretni i veseli :)

broker:
Apsolutno se ne slazem sa ovakvim pristupom. Ispadne to uvek po onoj staroj: ko ne plati na mostu, platice na cupriji. Srz svake baze podataka je model. On mora da se radi skolski postujuci sva nacela. Svako odstupanje od nacela mora da bude opravdano jakim razlozima medju kojima ne moze da bude: ovako je brze napraviti i radi posao, svi sretni i zadovoljni.


Da ne ulazim u polemiku, ovo je vrlo kontradiktorno. Kao reply na tezu "vazno je snalazenje - samo da radi" ti stavljas "da, ko ne plati na mostu - placa na cupriji".

To je bas ono sto ja hocu da ti kazem: ko ne projektuje od pocetka kako treba, vec budzi samo da radi, kasnije dodje u situaciju da mu se visestruko vrati tih par desetina minuta koje je ustedeo "budzeci" od pocetka.

Dozvoljavam bilo kakvu pricu, samo nemojte da pricate da je to resenje koje ste ponudili jednostavnije, kvalitetnije, brze, isplativije,... jer je upravo suprotno od toga.

BTW, ovo nije 1-m nego m-m relacija... svaki proizvod moze biti u vise kategorija, a u svakoj kategoriji moze biti vise proizvoda.... klasican m-m, a to se zna kako se radi. Ovako sigurno ne.
[ Dejan Topalovic @ 17.05.2004. 03:17 ] @
Citat:
broker:
Uzmimo jednostavan slucaj gde svaki proizvod moze da bude u vise kategorija
...
Ako je pred aplikacijom takav zahtev da ne treba vise od 4 kategorije, onda ovo ima smisla, narocito za web aplikacije, jer se time stvari dosta pojednostavljuju (web korisnicki interfejs se uproscava).
...
Ima veze, napraviti interfejs za unosenje sloga koji ima cetiri lookup poljaje prosta stvar, a napraviti interfejs koji omogucava da se unose podaci u tabele vezane u 1-n relaciju nije bas tako mali posao. Ko tvrdi drugacije slobodno nek mi da link na nesto sto je jednostavno, UNIVERZALNO, i radi taj posao kako treba.

Odluci se da li pricas o 1-n ili n-n. Kakva cetiri lookup polja?

Citat:

Pricamo o konacnom resenju. Imao sam u mnogo navrata priliku da radim modeliranje baza u kojima su bili bas takvi zahtevi, konacan broj lukap veza ka nekoj tabeli.
Milsim da je sasvim logicno da kada diskutujemo uvek podrazumevamojasno definisan zadatak, dobro projektovan sistem i da nema sta bi bilo kad bi bilo.

Pri projektovanju baze, odnosno tabela, uvijek se treba voditi racuna o fleksibilnosti doticne strukture za zeljenu aplikaciju. Pod tim se podrazumijeva izmjena aplikacije, a samim time i strukture baze, koja bi se morala izvesti na sto laksi i brzi nacin, a da opet bude efikasno i optimizovano. Pozeljno je izvrsiti sto vise stepena normalizacije, a minimalno 1NF.
Zasto da se ogranicavas u vezi bilo cega, pa tako i broja lookup-a tablica ili polja ?

Ti pravis (u ovom slucaju) web interfejs na osnovu potreba doticne aplikacije, a samim time i projektovane baze, a ne pravis bazu na osnovu web interfejsa. Prema tome, sto bolje i jednostavnije napravis bazu, lakse ce ti biti napraviti i web interfejs.

PS: Sorry na quotanju, odgovor se nalazi na drugoj stranici, pa da se ne izgubi misao.
[ broker @ 17.05.2004. 16:45 ] @
Citat:
bluesman:
Da ne ulazim u polemiku, ovo je vrlo kontradiktorno. Kao reply na tezu "vazno je snalazenje - samo da radi" ti stavljas "da, ko ne plati na mostu - placa na cupriji".

To je bas ono sto ja hocu da ti kazem: ko ne projektuje od pocetka kako treba, vec budzi samo da radi, kasnije dodje u situaciju da mu se visestruko vrati tih par desetina minuta koje je ustedeo "budzeci" od pocetka.


Hm, pa ovo sto si rekao se u opstem slucaju svodi na ono sto sam ja rekao: ko ne plati na mostu, platice na cupriji. :)

Citat:

BTW, ovo nije 1-m nego m-m relacija...


Dobro, lupiio sam. Vadicu se na sitne sate :)

Citat:
StRiPy:
Kakva cetiri lookup polja?


Ako covek kaze da jedan prozivod moze da bude u najvise cetiri kategorije onda je njegovo resenje da u jedan slog uvede cetiri polja kojima se pravi veza ka kategorijama upotrebljivo. Nisam mislio da treba da objasnjavam sta mislim po lookup polje.... al dobro

Citat:

Pri projektovanju baze, odnosno tabela, uvijek se treba voditi racuna o fleksibilnosti doticne strukture za zeljenu aplikaciju. Pod tim se podrazumijeva izmjena aplikacije, a samim time i strukture baze, koja bi se morala izvesti na sto laksi i brzi nacin, a da opet bude efikasno i optimizovano. Pozeljno je izvrsiti sto vise stepena normalizacije, a minimalno 1NF.
Zasto da se ogranicavas u vezi bilo cega, pa tako i broja lookup-a tablica ili polja ?


Teorija isto tako kaze da ne treba insitirati na postovanju NF ako to moze da zakoplikuje aplikaciju i utice na performanse. Stavise, nije redak slucaj da se normalne forme namerno narusavaju, jer se time brze dolazi do podataka. Teorije normalnih formi uopste nje iskljuciva i zasniva se na preporukama pravila kojih se treba drzati ali ne po svaku cenu. U praksi se najcesce ide do 3NF, jer preko toga stvari umeju da postanu nepotrebno komplikovane.

Ja ne kazem da je ovaj konkretno takav (cak se ispostavilo da je upravo napravljena greska u startu sto nije postovan opsti slucaj i koriscena m-n veza, sto sam ja u prethodnoj poruci vrlo jasno rekao) ali postoje slucajevi, sretao sam ih u paksi de je u samom zadatku bilo iskljucivo ogranicavano da se ne radi o m-n vec o m-c vezi gde je c konstantan broj, bez ikakve mogucnosti da se to u buducnosti menja.

Citat:

Ti pravis (u ovom slucaju) web interfejs na osnovu potreba doticne aplikacije, a samim time i projektovane baze, a ne pravis bazu na osnovu web interfejsa. Prema tome, sto bolje i jednostavnije napravis bazu, lakse ce ti biti napraviti i web interfejs.


Uh... ponavljas ono sto sam ja vec rekao i to kao argument protiv necega sto sam rekao govoreci o mogucim IZUZECIMA.

Da se razumemo, pricamo o istom i slazemo se kada je teorija u pitanju i mislim da je to ocigledno.

Ja govorim o izuzecima koje teorija takodje postuje samim tim sto dozvoljava da se od pravila odstupi kada se proceni da ce se time dobiti na kvalitetu resenja. Radi se o tome da se prilikom projektovanja sve uzima u obzir pa i buduca aplikacija koja ce da radi na modelu.

Isto koliko sam apsolutno protiv toga da se ne postuju pravila da bi se na precac napravila aplikacija koja radi, isto tako sam protiv da se iskljucivo drzi teroije i da se nastoji da se postuju sva pravila, po cenu da se aplikacija u krajnjoj implementaciji nepotrebno zakomplikuje (a vidjao sam i takvih resenja). Kljucna rec je optimalno resenje.

Kada je web u pitanju, korisnicki interfejs ima znacajnije mesto u procesu projektovanja baze u odnosu na klasicne desktop aplikacije i to samo iz jednog razloga: web interfejs je po definiciji znatno slabijih mogucnosti i samim tim predstavlja ogranicavajuci faktor.
[ NetworkAdmin @ 17.05.2004. 21:44 ] @
Cujte istina je da sam tu tabelu zadrzaocak i za next release iako je to bila adhock operacija.

Neku vece moj poznanik sa icq kojeg rece dva mudra postulata:

Citat:
1. KISS
2. If it ain't broken, don't fix it


Gdje KISS stoji za:
Citat:
Keep It Simple Stupid


Ima istine u tim rjecima.

Cujte sad bi me vjerovatno flame da vam kazem sta sam napravio na jednoj tabeli, ubacio sam kopiju polja iz druge tabele koja ima deset puta manje rekorda dakle ubacio sam value, key iz jedne tabele i kopiju kos jednog polja koji se moze navi preko tog key u prvoj tabeli...

Eto sad me flejmujte koliko gocete ali kad vam kazem da u toj tabeli ima stopedest miliona rekorda i da ce biti milijarda i da ovako query traje 0.3 sekunde a trajao bi 147 sekundi inace... sve ce vam biti jasno.
[ Dejan Topalovic @ 18.05.2004. 00:13 ] @
Ok, dali smo odgovor, pa da tema ne ode previse offtopic ili da se ne pocne neki flame, zakljucavam ju.
Drago mi je bilo cuti razlicita misljenja i konstruktivne savjete.