Problemi sa kombinovanim primarnim kljucem!

Imam tri tabele,definicije izgledaju ovako...

CREATE TABLE Partner(SIFPAR smallint CONSTRAINT sifpar_pk PRIMARY KEY,
PIB integer,
NAZIV varchar(20),
SIFDRZ smallint)

CREATE TABLE Ugovor(BRUGO smallint,
DATUGO datetime,
SIFIZL smallint,
SIFPAR smallint CONSTRAINT sifpar_fk REFERENCES Partner(SIFPAR),
VREUGO money,
CONSTRAINT brugo_sifizl_pk PRIMARY KEY (BRUGO,SIFIZL))

CREATE TABLE Izlozba(SIFIZL smallint CONSTRAINT sifizl_fk REFERENCES Ugovor(SIFIZL),
NAZIZL varchar(30),
DATPOC datetime,
DATZAV datetime)

Naime,kada pokusam da Execute-ujem trecu,prijavljuje mi gresku: ''There are no primary or candidate keys in the referenced table 'Ugovor' that match the referencing column list in the foreign key 'sifizl_fk"

U object explorer-u lepo se vidi da je u tabeli Ugovor kreiran primarni kljuc nad kolonom SIFIZL!Sta ne valja?

U tabeli Ugovor je primarni ključ formiran nad DVE kolone BRUGO i SIFIZL, a ne nad samom kolonom SIFIZL. Iz tog razloga ta kolona i nemože da se referencira iz tabele Izlozba.

Ovakav problem me navodi da ti nešto sa dizajnom modela nije uredu.

Potpis

"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo

U tabeli ugovor mi treba primarni kljuc i na obelezju BRUGO da bih je mogao spojiti sa cetvrtom tabelom!Ne znam u cemu je problem,zar ne moze jedna tabela da ima dva primarna kljuca?

Jedna tabela može imati više ključeva, ali samo jedan može da bude PRIMARY. Smatraj primarni ključ kao default ključ. Ostali ključevi se definišu pomoću CREATE UNIQUE INDEX.

Potpis

"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo

Pozd.

Informacije su malo nabacane, i pomalo dovode u zabludu. Znachi ovako, jednom za svagda:


PRIMARNI KLJUC (PRIMARY KEY) je kljuch koji JEDNOZNACHNO odredjuje relaciju u tabeli. Sve kolone koje pripadaju primarnom kljuchu, NE MOGU IMATI VREDNOST NULL.

JEDINSTVEN KLJUCH (UNIQUE KEY) je kljuch koje NE ODREDJUJE JEDNOZNACHNO relaciju u tabeli. Sve kolone koje pripadaju jedinstvenom kljuchu MOGU IMATI VREDNOST NULL.

Mimika primarnog kljucha korishcenjem jedinstvenog kljucha bi bila samo, i samo u sluchaju da su sva polja u tabeli koja su deo jedinstvenog kljucha proglashena kao NOT NULL.

Svako dobro.

KLJUČ je kolona ili kombinacija više kolona koje jednoznačno određuju red.

SVAKI ključ JEDINSTVENO određuje red u tabeli. I da, može ih biti više, ali se samo jedan od njih može proglasiti za primarni ključ.

U svim sistemima za upravljanje bazama podataka se implicitno pri kreiranju primarnog ključa kreira i jedinstveni indeks nad kolonama koje taj ključ čine. Naravno sve te kolone moraju biti NOT NULL.

Jedini razlog zašto se od mase UNIQUE indeksa nad NOT NULL kolonama jedan proglašava za PRIMARY je da bi se on koristio kao default ključ prilikom referenciranja. jer postojanje PRIMARY KEY indeksa dozvoljava da se tabela referencira bez navođenja kolona koje učestvuju u referenciranju.

Dakle PRIMARY KEY je ustvari UNIQUE INDEX nad NOT NULL kolonama čija je jedina uloga da skrati zapisivanje referenciranja iz druge tabele.

Potpis

"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo

Pozd.

Opet malo problem sa informacijama, pa neko mozhe da neke stvari pogreshno shvati.

Nisi u pravu kada kazhesh da "svaki kljuch jedinstveno odredjuje red u tabeli".
Prvo, kljuch ne mora da bude UNIQUE - ovde je jasno da takav kljuch ne odredjuje jednoznachno jednu relaciju.
Drugo, UNIQUE kljuch definisan nad poljima koja mogu biti NULL, ponovo ne odredjuje jednoznachno jednu relaciju.

Primarni kljuch je kljuch koji implicitno zahteva da polja koja sadrzhi ne mogu biti NULL i ovo je neshto shto se ne ostavlja kao opcija korisniku da promeni, i samim time referencijalni integritet je apsolutno ochuvan, i bez ikakvog obzira na bilo koji parametar poput tipa polja u tabeli, ovaj kljuch ce UVEK jednoznachno odredjivati jednu relaciju.

Svako dobro.

Koliko sam ja shvatio tvoju strukturu, BRUGO bi trebalo da bude jedini primary key nad Ugovor tabelom. Pored njega naravno možeš da dodaš običan index nad SIFIZL poljem.
Takođe, možda bi hteo da pročitaš i MySQL stranicu o kompozitnim indexima.

Potpis

"Common sense is not so common." - Voltaire

Po svojoj definiciji ključ (ili da budem precizniji - superključ) jedinstveno određuje red u tabeli.

Uzmimo primer:

Oba atributa - i 'serijski_broj_sasije' i 'serijski_broj_motora' su sami za sebe ključevi jer jedinstveno identifikuju određeni automobil. Preciznije, oni su kandidatni ključevi. Ova činjenica se u SQL-u na žalost zapisuje upotrebom UNIQUE INDEX-a:

Pošto su ove dve kolone ključevi mogu da ih referenciram iz neke druge (treće) tabele:

Prilikom referenciranja na tabelu automobili, a pošto nisam definisao primarni (default) ključ, morao sam da navodim i kolone na koje se referenciram!

Sada mogu da se odlučim da proglasim 'serijski_broj_motora' za primarni ključ pomoću:


Pošto sam definisao primarni ključ (opet da ponovim u SQL terminologiji nije ništa drugo nego podrazumevani-default ključ) sada mogu nove reference da obavim BEZ navođenja kolona na koje se referenciram a sistem će za to iskoristiti moj default ključ:


Da rezimiram:
- tabela 'automobili' ima dva ključa i to su pojedinačne kolone 'serijski_broj_sasije' i 'serijski_broj_motora',
- podrazumevani (primarni) ključ za tabelu 'automobili' je kolona 'serijski_broj_motora',
- kada se referenciram na tabelu 'automobili' i hoću da se referenciram na kolonu 'serijski_broj_motora', tada nemoram (a mogu) da navedem tu kolonu jer je ona podrazumevana,
- kada se referenciram na tabelu 'automobili' i hoću da se referenciram na kolonu 'serijski_broj_sesije', tada moram da navedem i tu kolonu prilikom referenciranja.

Potpis

"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo

Pozd.

Vidim da se ovo sada pretvorilo u jeste-nije.

Hajde sada lepo i kulturno prihvati da tvoja izjava "svaki kljuch jedinstveno odredjuje red u tabeli" nije tachna.

Prochitaj josh jednom moj odgovor. Naveo sam ti 2 primera kada kljuch ne odredjuje jednoznachno relaciju (kada nije unique, i kada jeste unique ali jedno ili vishe polja kljucha je deklarisano sa NOT NULL), a ti sada pravish test sa upravo trecom mogucnosti kada je UNIQUE kljuch definisan nad NOT NULL poljem - nisam ni rekao suprotno, pogledaj poruku pre poslednje.

Neko ko ne zna toliko o SQL-u i kljuchevima ce prochitati tvoju izjavu "svaki kljuch jedinstveno odredjuje red u tabeli" i steknuce pogreshnu predstavu, zbog chega sam te ispravio.

A kada smo vec krenuli u opshtu raspravu o ovome da kazhem i sledece, za sve one manje upucene:

Primarni kljuch NEMA NIKAKVE fizichke razlike od jedinstvenog kljucha definisanog nad poljem ili poljima koja su deklarisana sa NOT NULL. Fizichka implementacija od strane DBS je u sushtini i nebitna, ali eto korisni je i to znati.

Primarni kljuch je nishta drugo nego lakshi nachin zapisa koji programeru olakshava kreiranje kljucha koji ce JEDNOZNACHNO odredjivati relaciju. Taj programer, kada kreira primarni kljuch, ne mora uopshte da razmishlja da li su polja koja zheli da iskoristi deklarisana sa NOT NULL jer ce DBS ovo da forsira, i ako su polja deklarisana sa NULL on ce to promeniti. Ovime se ne ostavlja mogucnost da neko mozhe sluchajno da naknadno promeni jedno ili vishe polja koja su deo primarnog kljucha u NULL. Ako probate da promenite (ALTER TABLE) tabelu i setujete polja koja su deo primarnog kljucha sa NULL, nishta se nece desiti, odnosno DBS ovo nece uraditi i polja ce ostati NOT NULL. U sluchaju jedinstvenog kljucha OVO NIJE TAKO, i kod (prema tvom primeru):



ce promeniti tip polja na NULL, i time efektivno narushiti namenjeno ponashanje kljucha ind_sasija. Zato postoji primarni kljuch kada ni prigramer niti bilo ko drugi ne mora da na ovakve stvari obraca pazhnju, jer je hardkodovano da primarni kljuch UVEK jednoznachno odredjuje jednu relaciju.

Pride moram da napomenem svima koji chitaju, nije preporuchljivo koristiti tekstualne tipove kao primarni kljuch, sa stava prvo optimizacije, a drugo i integriteta aplikacije koja treba da koristi takvu tabelu. U jednoj drugoj temi neko je koristio TEXT polje kao primarni kljuch - ovakva polja uchestvuju samo sa odredjenim brojem karaktera sa pochetka teksta u okviru kljucha, i time bi se desilo da ako imate dva teksta duzhine 1000, a u kljuchu to polje ima duzhinu 200, da ne mozhete da ubacite dva razlichita teksta ako imaju prvih 200 karaktera ista, iako su ostali karakteri razlichiti (odnosno drugachiji tekst je u pitanju). Za primarni kljuch najbolje je koristiti ordinalne tipove podataka kao shto je INT.

@chachka: Molim te da prochitash pazhljivo ovo shto sam napisao, jer ovome nema mesta raspravi.

Svako dobro.

EDIT: mali lapsus, napisao sam bio not null umesto null na jednom mestu :)

Tačno. Slično sam i ja rekao kada sam primarni ključ nazvao podrazumevanim ključem koji kasnije samo skraćuje (olakšava) zapisivanje.


Upravo sam zato i rekao da se NAŽALOST alternativni ključevi u SQL-u prave pomoću konstrukcije CREATE UNIQUE INDEX nad NOT NULL kolonama. Ali to je jedini način da se definišu alternativni ključevi.

S druge strane, izmena metapodataka jedne baze nije akcija koja se izvršava slučajno. Na taj način bih ja kao neodgovoran database administrator slučajno mogao da dropujem PRIMARY KEY constraint i da nakon toga dozvolim da NOT NULL kolona može da prima NULL vrednost. Takođe slučajno mogu da dropujem i celu tabelu.


@stsung: Pažljivo sam pročitao sve što si napisao i slažem se da nema mesta raspravi jer se o definicijama jednostavno ne raspravlja! Definicije se prihvataju takve kakve su, a definicija ključa kaže da je: ključ atribut ili kombinacija atributa koji jednoznačno određuju torku u relaciji, prevedeno na SQL terminologiju: ključ je kolona ili kombinacija kolona koje jednoznačno određuju red u tabeli.

Cela nesuglasica nastaje jer ti pojam 'ključ' (KEY) posmatraš kao sinonim za pojam 'indeks' (INDEX) kako stoji u MySQL terminologiji, dok ja pojam 'ključ' posmatram onako kako je definisan u relacionoj teoriji.

Relaciona teorija ne poznaje pojam 'indeks', koji se pojavljuje u SQL bazama podataka, a kojeg je MySQL zajednica poistovetila sa pojmom 'ključ'. I to je jedan od razloga zašto sam koristio onu reč "nažalost" pri korišćenju indeksa za definisanje kandidatnih ključeva.

Kad sam prvi put rekao "Jedna tabela može imati više ključeva", o ključu sam govorio u njegovom najširem smislu bez obzira da li se radi o superključu ili o kandidatnom ključu ili o primarnom ključu, a najširi smisao ključa je dat u njegovoj definiciji.

Nepobitno je da jedna tabela može da ima više ključeva. To što DBA može da uništi ključ nije kontraargument. DBA može da uništi celu bazu, pa to nije osnov za tvrdnju da baze podataka nepostoje!

Potpis

"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo

Pozd.

Ipak smo u MySQL forumu, i komentarishemo o kljuchevima, odnosno o indeksima hvala na ispravci, kakvi su implementirani u MySQL. Drugi DBS se drugachije ponashaju, ali to nije tema. Pricha se u stvari malo razvila od postavljenog pitanja, a u cilju da drugima koji ovo chitaju bude jasnije shta se u stvari deshava.

Naravno da mozhesh "sluchajno" da uradish svashta. Konkretnije, mozhesh ako imash privilegiju za tako neshto, ako nemash DROP privilegiju mozhesh da probash jel :) No, tom logikom ispada da MySQL ni ne mora da ima primaran kljuch, kada se uvek mozhe napraviti UNIQUE index nad NOT NULL poljima. Mozhemo sve i da pishemo na tablicu klinom umesto u bazu, mislim svashta zaista mozhemo, ali to nije uopshte poenta niti je argument protiv. Kada ne radish projekat sam, vec sa josh 30 ljudi, ovo malo menja sliku. MySQL nam je dao mogucnost da kada kreiramo primarni indeks ( :) ), zaboravimo na opcije da je ovo moguce promenuti na nachin da primarni indeks vishe ne odredjuje jednoznachno relaciju u tabeli. Ali ti kao DBA, nemash toliko uvida u business logiku koja ce trchati nad tom bazom. Ti vidish schemu, koja je zajednichkim radom programera, prema uslovima projekta, dobila svoj oblik, i tvoje je da takva schema zadovoljava sve uslove relacionog modela, kao i projektovanu business logiku (na primer, necesh dozvoliti svakome da DROP-uje tabele po bazi, kao ni svakome da mozhe da radi SELECT nad poljem tabele gde su zapisani brojevi kreditnih kartica, ili INSERT u tabelu smrtne_kazne :). I zbog toga, ti cesh recimo kreirati auto increment polje i njega koristiti kao foreign key ka povezanim tabelama (shto je generalno najcheshca opcija, iako mozhe da napravi malo problema kod replikacije), a to da li ce neko da (na primer) kreira polje za broj registarske tablice kao CHAR(20) ili kao TEXT, to nije tvoj problem. Taj isti neko mozhe da shvati da se zeznuo i da sada zheli neshto drugo (recimo primer JMBG ... deshava se da dve iste osobe imaju isti JMBG, shta cesh sistem nije savrshen ovo se desilo mome kolegi, i programer se nasho u problemu da mu to polje vishe nije UNIQUE ... banalan primer, ne pada mi na pamet sada neshto pametnije).

Ideja cele priche je bila da posetiocima koji nisu toliko vichni, i koji ne razumeju zashto tabela ne mozhe da ima dva primarna kljucha, malo priblizhimo celu prichu, na nachin na koji je MySQL to implementirao. Zato sam morao da te ispravim vezano za tvoju izjavu, jer ce neko da pomisli da bilo koji index koji kreira mozhe da koristi kao FK bez problema.

Na kraju, kao shto sam napomenuo, uopshte nije dobra ideja koristiti tekstualne tipove za FK. Manje je optimizovano, i imamo vec navedene probleme vezano za blob polja. Preporuchuje se korishcenje ordinalnih tipova poput INT.

Svako dobro.

I nemože tabela da ima dva primarna ključa, i to nigde nisam ni rekao. Rekao sam da tabela može da ima dva ključa, a ne dva primarna ključa


Nemože bilo koji index da se koristi za referenciranje kroz foreign key, ali može da se koristi uniqe index nad not null kolonama, što sam kroz primer i demonstrirao.


Ako aludiraš na moju upotrebu VARCHAR(25) tipa za ključnu kolonu, molim te - nemoj! VARCHAR ključ je dat samo zbog jednostavnosti primera. Primer je dat zbog jasnosti da nebih uvodio neku kolonu sa nazivom 'sifra', 'id' ili tako nešto slično.


Da li je INT brži i optimalniji od CHAR(4)? Hm... morao bih da eksperimentišem... ali mi logika govori da nije! I INT i CHAR(4) se mašini prikazuju kao niz podataka od 32 bita. Uopšte nevidim razlog zašto bi mašina sa jednim nizom podataka od 32 bita radila brže nego sa drugim nizom podataka od 32 bita!

I da, upotrebio sam adekvatnu reč "podatak" jer je to upravo ono što mašina vidi - podatak i ništa više. Da li je taj niz broj 16384 ili string 'Pera' to mašina nezna, tu smisao nizu od 32 bita daje tek čovek.

Potpis

"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo

Pozd.

Ti bash volish da se raspravljash :) Prochitaj josh jednom shta je napisao postavljach teme ... he majku mu moram sve da crtam. Postavljach je taj koji je zbunjen zashto ne mozhe 2 primarna kljucha.

Vezano za VARCHAR primer ... hajde sada ovako : ovo je forum. Ovo nije prepiska izmedju mene i tebe. Ovo chitaju i drugi. Ja skrecem na pazhnju CHITAOCIMA na dobre navike u radu sa MySQL, valjda mozhesh majku mu da prepoznash kada mislim na konkretno tvoju izjavu a kada govorim uopshteno.

Za CHAR(4) ... skoro sam siguran da je isto kao sa INT .. ali koja je svrha podatka CHAR(4) ? Sigurno postoji, ali se ne koristi toliko chesto. JMBG bi imao 13 karaktera, registracija bi imala 8, i tako dalje. Ako naletish bash da imash jedinstvan SMISLENI podatak u tabeli koji treba da je jedinstven i upada u CHAR(4), eto super, bravo, nashao si kandidata za primarni kljuch. No u vecini sluchajeva ovo nece biti tako, i zato je najbolje CHITAOCIMA skrenuti ovo na pazhnju - naveo sam da je u jednoj temi chovek hteo da koristi TINYTEXT kao primarni kljuch - ovde ima puno pochetnika, josh jednom podvlachim da ovo nije prepiska izmedju mene i tebe.

Valjda je sada sve jasno, hocesh da nastavljamo raspravu i dalje? Jako ti je teshko da kazhesh kad neshto pogreshish - svi greshe, pa i ja. Sada cemo izgleda raspaliti 10 poruka kako je CHAR(4) u stvari smislen podatak i kako nema nikakve razlike blablabla.

Svako dobro.

Pokretač teme jeste zbunjen. Toliko je zbunjen da misli da se referenciranje na drugu tabelu može izvršiti samo preko primarnog ključa. I kad mu je usfalilo referenciranje po drugoj koloni on je zbunjen i pita se zašto to ne mogu da uradim? Zašto ne mogu i tu kolonu da proglasim primarnim ključem? Toliko je zbunjen da pokušava da napravi dva primarna ključa jer mu treba referenciranje na dva ključa.

Rešenje je u tome da se referenciranje može vršiti i po kolonama koje nisu definisane kao 'PRIMARY KEY'. Naravno te kolone moraju da zadovoljavaju uslove: jedinstvenosti i nesmeju da sadrže NULL vrednost.

Standardni postupak modeliranja opisan u bezbroj knjiga:
1. Napravi se prva tabela.
2. Napravi se primarni ključ prvoj tabeli.
3. Napravi se druga tabela.
4. Napravi se strani ključ u drugoj tabeli koji se referencira na primarni ključ prve tabele.
5. itd
U koliko knjiga je napisano da se referenciranje nemora isključivo upotrebljavati sa primarnim ključem? (Ja ne znam ni za jednu takvu knjigu, a pozivam čitaoce ove teme da ukažu na knjigu u kojoj je objašnjeno referenciranje na kolone koje nisu primarni ključ.)

Čitanjem takvih knjiga se stiče pogrešan zaključak da se referenciranje MORA vršiti preko primarnog ključa, a stvarnost je da se refeneciranje MOŽE obaviti i preko bilo koje jedinstvene NOT NULL kolone. Mehanizam za to je da se takva kolona proglasi kao UNIQE INDEX.

Možda su baš dva ključa ono što je pokretaču teme potrebno, ne dva primarna ključa kako ih je on nazvao, nego dva ključa (bez ikakvih prideva).


---

Poenta upoređivanja CHAR(4) i INT tipova je u tome da netreba biti isključiv pri odabiru tipova podataka i reći: "uvek treba koristiti INT".

Jaja se označavaju klasama "A", "B", "C". Ovo su ustvari kodovi kojima se jedna karakteristika stvarnog jajeta beleži slovom. Zar nije logično da se i u bazi za klasu jajeta upotrebi tip CHAR(1)? Ili je logičnije da za postojeću kodnu šemu (A, B C) napravimo dodatno kodiranje pomoću tabele:
i da ih non-stop JOIN-ujemo

Potpis

"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo

Pozd.

Ovako, sata si stvarno preterao i ovo je poslednja poruka koju pishem na ovu temu - ti cesh ovako da se raspravljash do sudnjega dana.

Nisam rekao "UVEK TREBA KORISTITI INT" vec "Preporuchuje se korishcenje ordinalnih tipova poput INT.".

Prvo: PREPORUCHUJE, izvoli otvori rechnik i vidi razliku izmedju "PREPORUCHUJE" i "UVEK".
Drugo: Izvoli do sudnjega dana slobodno trazhi smisao CHAR(1) ili CHAR(4)
Trece: Veoma hvala shto nemash toliko pristojnosti da se IZVINISH (opet konsultuj rechnik ako ne znash shta to znachi) zato shto si pogreshno razumeo i ochigledno brzopleto BEZ RAZMISHLJANJA tvrdio stvari poput "I nemože tabela da ima dva primarna ključa, i to nigde nisam ni rekao. Rekao sam da tabela može da ima dva ključa, a ne dva primarna ključa" a POJMA NEMASH shta je pokretach teme uopshte pisao. Ja ZNAM da je pokretach teme zbunjen. Ja ZNAM shta je pokretach teme napisao, shto se za tebe ochigledno ne mozhe reci, vazhno je da si odma skochio i da ti je tashtina ukljuchila samoodbranu u stilu "to nigde nisam ni rekao". Skoro da mogu da pretpostavim da si maksimalno ne-timski igrach, i da bi bio nemoguc kada bi bio ukljuchen u nekom vecem timu ... poznata sorta, dodju nabedjeni kako sve znaju i onda krenu da rade suprotno nachinu koji je postavljen od strane tima sa komentarima poput "radi to i ovako", "ovako treba".
I na kraju, evo prilike i da se obogatish :

Guinness World Records Limited
184-192 Drummond Street
3rd Floor
London NW1 3HP
United Kingdom

Njima poshalji aplikaciju da si jedini chovek na planeti koji nikada nije greshio.

Ignorishem ovu temu, na pamet mi ne pada da se raspravljam - sledece ce biti dokazivanje da "preporuchuje" i "uvek" oznachavaju istu stvar. Ako imash neki lichni problem protiv mene mozhesh jedino da mi uputish PM, a ja isto tako mogu da na PM odgovorim ili ne. Dosta vishe smaranja ostalih zato shto je "veliki gospodin" pogreshio ili napravio lapsus pa sada nema ni toliko integriteta da kazhe pogreshio sam. Zdravo.

@stsung: Naravno je da ću se raspravljati - pa to si i ti činio u proteklim postovima. Naravno postoji još jedan razlog zašto odgovaram na tvoj post, a to je da ti dam priliku da postupiš po onoj narodnoj "pametniji popušta". Eto ja ne popuštam, a ti izvedi zaključak.

Da si zaista hteo da prebaciš ovu besmislenu raspravu na PM, to bi i uradio pre predhodnog posta u kojem mi savetuješ da otvorim rečnik i u kom me karakterišeš kao nepristojnog, sudiš o mom timskom duhu i upućuješ me da apliciram za Ginisovu knjigu rekorda. To valjda dovoljno govori o tvojoj pristojnosti.

Jesam pogrešio u jednom i tu nemam nameru da se raspravljam - pogrešio sam kada sam tvoju preporuku o korišćenju INT-a shvatio kao bezuslovno korišćenje INT-a. Nemam potrebe da se izvinjavam jer mi namera nije bila da te tom prilikom uvredim ili diskreditujem.

I za kraj, tvoje reči "[ti] POJMA NEMASH" i "Ja ZNAM" dovoljno govore o tome ko je od nas dvojice "veliki gospodin" i ko je bezgrešan.

Potpis

"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo

Pametniji zaista popushta, ali ja ipak necu dozvoliti da me blatish i da ti to prodje bez replike.

Ne znam da li imash neki mentalni problem, ali ne dozovljavam da citirash moje izjave, koje uopshte nisu moje i koje ja nikada nisam rekao. Ovo konstantno radish i ja ne dozovljavam da mi se pripisuju stvari koje nisam rekao i da mi se stavljaju rechi u usta. "[ti] POJMA NEMASH" i "Ja ZNAM" isto kao i "UVEK TREBA KORISTITI INT" ja nigde nisam rekao, a ti si me citirao. Ja sam te ispravio a ti odbijash da prihvatish da si pogreshio, skoro kao da si uveren da su to moje izjave. Ako nalazish citate tamo gde ne postoje i uveren si u to, sa tobom neshto nije u redu mentalno. Ako budesh dolazio u NS javi se, radim i u KBC i ugovoricu ti besplatno pregled kod koleginice na psihijatrijskoj klinici, jer nimalo nije normalno da se nekome tvojih godina prividjaju stvari.

Neka me neko drugi ispravi ako nisam u pravu (ZNACHI NEKO DRUGI - NE TI!!!), a moderator mozhe slobodno da poslednjih par poruka izbrishe. A ti prekini da citirash stvari KOJE NIKADA NISAM REKAO.