pa ako se baviš bilo kakvim financijama, onda ti je jasno da sad i ako strane osobe žele nešt trgovati moraju imati OIB kod nas, pa eto ti čisti konkretni primjer…
takozvani “web 2.0” se po logici uopće ne razlikuje od normalnih webova, razlika je samo ako koristiš ajax da ne učitavaš cijelu stranicu nego samo neke detalje, ako ti misliš da prije web 2.0 se nije koristio master-detail veoma si u krivu, tu se ama baš ništ nije promjenilo, nikakvi upiti ni ništ… ne kužim odakle ti opće ideja da “web2.0” ima bilo kakve veze s bazom?
I prestanimo koristiti taj termin web2.0 taj web2.0 opće ne postoji…
a hashat stringove i pucat u bazu kao primary key je fakat ludo, ja sam i dalje rekao da je uvijek bitna domena, ti stvari guraš preopće. Isto primjetio sam uzmeš moju situaciju i izmijeniš neke važne stvari u njoj i onda govoriš da nije važno, pa gledaj onda ovo (zamišljena situacija) na svijetu postoji standard kojim se sve zgrade označuju i nemoguće je imati dvije baze s istim imenom/oznakom
[quote=“trnac”]Logika je univerzalna i nema veze s geografskim položajem.
[/quote]
Što znači što?
Da svugdje dva istinita suda daju istinit zaključak ili to znači da ako je u RH poštanski broj jedinstven da je u cijelom svijetu.
Da pitam se odakle mi ideja da web aplikacije imaju nešto s bazom, pogotovo web 2.0 aplikacije.
Što želiš reći da je web 2.0 to da se stranica nerefreshira?
[quote=“gorrc”]Što znači što?
Da svugdje dva istinita suda daju istinit zaključak ili to znači da ako je u RH poštanski broj jedinstven da je u cijelom svijetu.
Da pitam se odakle mi ideja da web aplikacije imaju nešto s bazom, pogotovo web 2.0 aplikacije.
Što želiš reći da je web 2.0 to da se stranica nerefreshira?[/quote]
Baš sam pogledao ta famozna 4 grada koja imaju isti poštanski broj.
Radi se o “gradovima” koji su međusobno udaljeni 3-4 km.
Kako su dosta blizu, sigurno se nazivi ulica moraju razlikovati jer teško da imaju iste nazive ulica svaka 3-4 km.
U svakom slučaju, primjer koji po meni ne drži vodu.
Zatupam ideju da se radi vlasiti ključ kod osoba odnosno da se ne koristi nikakav broj dodijeljen od državnih ustanova.
Za poštanski broj bi mi se moralo dati neki jači razlog od ovog da ge ne smatram unikatnim unutar države.
Što kažeš na valute i države? Treba li i za njih generirati ID ili se ipak može pouzdati u ISO standard?
Zračne luke također imaju svoje međunarodne oznake. I za njih treba generirati vlasititi ID?
Stvar nije crno-bijela i dosta ovisi o iskustvu i znanju osobe koja dizajnira bazu.
Primjetio sam da neki koriste iso.
No meni to otvara previše pitanja.
Imamo pola milijuna korisnika kojima je defaultna valuta u bazi HRV. Dođe EU kao defaultna valuta za te korisnike i treba raditi update na svakog korisnika koji je koristo HRV.
I svaki prirodni ključ je pod utjecajem toga.
Tko veli da se sutra županije neće raspasti i da neće donjeti nove brojeve.
Zato treba biti iskusan i imati znanja, ali se može drugačijim pristupom izbjeći takvi problemi. A nisam vidio nikakve mane drugačijeg pristupa osim naravno što key koji baza kreira nema nikakvog značenje van baze.
Možda neke stvari treba bolje posložiti.
Npr. valutu ne vezati za korisnika nego za državu. Kada (nadam se nikad) dođe do promjene da HR mijenja kunu u EUR, izmjena je na jednoj poziciji.
Glede županija…to mi ide na jetru koliko sajtova vidim koje u tražilici imaju podatak županije. Vjerojatno je netko nekad napravio takav upit i onda su svi to počeli koristiti.
Da, podatak o županiji je totalna bedastoća osim ako nisi županijiski statistički centar. :zub:
ali gle ti kad ideš dizajnirat bazu prenašaš ono što znaš kako bude i kako treba biti u strukturu baze, moraš unaprijed sve znati i onda ideš postavljat bazu, a ne da razmišljaš što ako se dogodi ovo što ako se dogodi ono, moraš imati jasno definirano što se može dogoditi, a što ne, ionak nećeš jedan software koristiti dovjeka, software se mjenja s njim i baze, ako se dogode tako velike promjene jednostavno ćeš preraditi bazu prenijeti podatke i gotovo, ne kompliciraš si stvari odmah u startu…
[quote=“trnac”]Možda neke stvari treba bolje posložiti.
Npr. valutu ne vezati za korisnika nego za državu. Kada (nadam se nikad) dođe do promjene da HR mijenja kunu u EUR, izmjena je na jednoj poziciji.
[/quote]
This one was even more far reaching. In Slovenia (my home country) we have something called a Tax ID. This is an ID that is unique for companies and individuals so every person and every company has one for tax purposes. Many systems in Slovenia used it as the natural never changing key which sounded like a reasonable thing at the time. And it was so for over 30 years. Applications came and went. But in 2004 Slovenia entered into the European Union. So we had to modify the TaxId to European standards which means that every application using it had to be changed. I know of at least one company that went out of business because of this change. Again had they used a surrogate key the only change would be the length of the TaxId column.
[quote=“gorrc”]Dizajniram bazu da određeni djelovi na bazi moraju imati mogučnost unošenja prijevoda.
Najednostavniji primjer vijesti.
Za sad neka bude jedna tablica novosti.
Treba nam još jedna tablica za prijevode tekstova.
Jedna tablica za popis jezika.
Ovo se fino može povezati bez nekih problema.
[/quote]
Pa cak se i ne treba “povezivati” u trecoj tablici, ja osobno bi dodao kompozitni primarni kljuc - id, jezik (npr. 5, “hr”). Pa tako za istu vijest na razlicitim jezicima mozes imati isti id, sta moze biti jako korisno u nekim situacijama (a i semanticki je ispravan model).
[quote=“gorrc”]
Uglavnom ništa što se kvalitetnim dizajnom ne može rješiti no mislim barem iz toga konkretnog primjera da ako tablicu koristi više drugih tablica ili u budućnosti postoji mogučnost da bi mogle biti novih tablica povezanih s tom tablicom. Ta tablica nebi trebala imati foregin key već isključivo povezivanje s drugim tablicama preko drugih tablica, ako je naravno to moguče.[/quote]
U ovom tvom slucaju treca tablica mi se cini najbolje rjesenje, medjutim, opcenito ne mora biti.
S tim da se moze rjesiti i sa FOREIGN KEY-em, samo sta ne bi upit radio ovako:
“Select * from vijest where zupanija is null, tvrtka is null and privatni_osobe not null”
Nego ovako:
“SELECT * FROM vijest, privatni WHERE vijest.privatni_osobe = privatni.id”
uz eventualno dodatak “vijest.zupanija IS NULL” i “vijest.tvrtka IS NULL” u WHERE dijelu, ali ako to ima smisla, to jest - ako zelis dohvatiti vijesti privatne osobe koje nisu u ni jednoj zupaniji ni tvrtki (semantika upita je bitna).
[quote=“ivan.skugor”]Pa cak se i ne treba “povezivati” u trecoj tablici, ja osobno bi dodao kompozitni primarni kljuc - id, jezik (npr. 5, “hr”). Pa tako za istu vijest na razlicitim jezicima mozes imati isti id, sta moze biti jako korisno u nekim situacijama (a i semanticki je ispravan model).
[/quote]
Stavio sam još polje objavi i završi s objavom i sad to ne mogu primjeniti jer će mi se ponavljati vrijeme objave i završetak objave.
[quote=“ivan.skugor”]Pa cak se i ne treba “povezivati” u trecoj tablici, ja osobno bi dodao kompozitni primarni kljuc - id, jezik (npr. 5, “hr”). Pa tako za istu vijest na razlicitim jezicima mozes imati isti id, sta moze biti jako korisno u nekim situacijama (a i semanticki je ispravan model).
[/quote]
Odlučio sam to ipak ovako rješiti. Iako će se ponavljati vrijeme i kraj objave, to će biti feature a ne bug.:kuc:
Tako će i svaki prijevod imati mogučnost vremenskog određivanja koliko će vijesti biti aktivna.