Re: ADO.NET i izdavanje racunaCitat:
Pharos: A što za ID ne koristite GUID, a za "govoreće" šifre (broj računa) drugo polje tipa string/int?
Zatim, zar nije jako loše rešenje koristiti auto increment polja u bazi?
Zatim, zar nije jako loše rešenje koristiti auto increment polja u bazi?
Ako se import radi kroz replikaciju postoje mehanizmi za sinhronizaciju kljuceva (sto je inace jos jedan razlog zasto ne koristiti ID za broj racuna). GUID to resava univerzalno ali ja npr izbegavam koriscenje GUIDa sem kad je apsolutno neophodno zbog performansi joina i svih ostalih operacija jacih od O(1). Kad poredis dva GUIDa za join poredis dva 16-bajtna bloba koji nisu prilagodjeni arhitekturi danasnjih procesora, u principu GUID kljuc ima iste performanse kao char(16) kljuc. Sa druge int kljuc je 32bita i poredjenje moze da se obavi kompletno registarski. Kad i koristim GUID to je za tabele kroz koje cetokom zivota aplikacije proci vise od 2^31 redova.
Auto increment je veoma optimizovan i skalira se lepo po svim transaction izolacijama i lock granulaciji i keygen radi direktno iz memorije servera bez potrebe za dodatnim validacijama. Zbog toga inace i nastaju rupe (ako rollbackujes transakciju ID counter se ne rollbackuje jer je sledeci kljuc mozda vec izdat drugom procesu, SQL6.5 je imao ovaj bug vracao je counter unazad na rollbacku, ali je reseno u 7.0).
Na kraju GUID nije univerzalno jedinstven, samo je statisticki veoma veoma mala sansa da se pojave duplikati.
To su nekad govorili i za JMBG 
Citat:
Astek: 2. Zatim snimim racun(u tu svrhu koristim SP koja mi kao output parametar vrati ID preko @@identyti)
Moja preporuka ti je da koristis SCOPE_IDENTITY() umesto @@identity. Ako neko nekad zakaci insert trigger na tvoju tabelu (npr zbog audita) i taj triger insertuje neki red negde drudge, @@identity ce se pormeniti na ID iz te druge tabele, dok ce SCOPE_IDENTITY() i dalje ostati postavljen na tvoj novi ID.
Citat:
mkaras: Čini mi se da baš i ne razumeš to što pišeš jer pišeš o stvarima o kojima niko nije ni pričao. Ta "opsesija" je nekada srž problema i mora se ispoštovati. Dobro si rekao da osnovna svrha ID nije nošenje korisničkih informacija pa ze za takve stvari i ne koristi i niko nije rekao da mora da postoji kontinualnost ID-jeva, ali zato mora da postoji kontinualnost brojeva računa u fiskalnoj kasi, kontinualnost brojeva serije čekova koji se izdaju, kontinualnost serijskih brojeva karata za neki koncert, voz, ringišpil, ... A ako znaš da napišeš funkciju onda možeš na kartama da štampaš broj reda i sedišta, ili broj vagona, kupea i sedišta, i da širimo dalje. Postoji veoma mnogo prilika kada je taj tvoj ID nekoristan za sve osim za povezivanje tabela
Ta opsesija nikad nije srz problema i uvek postoji bolje resenje od koriscenja rucno generisanih kljuceva u tu svrhu i ne mora se uvek ispostovati. A i ton ti nije prilagodjen kao ni opaska, bar da ne radim consulting u bankarskom sektoru pa da ti i poverujem. Serijske brojeve na cekovima ne generise banka u konkurentskom rezimu, serijske brojeve cekova generise stampar istih (u nasem slucaju zavod za izradu novcanica), banka te cekove duzi i razduzuje svojim klijentima a po vec odstampanim serijskim brojevima. Sta vise "rupe" u brojnom sistemu cekova su relativno cesta pojava (kad banka komisijski unisti ili vrati stamparu neispravno odstampane cekove pre zaduzivanja, ti brojevi se vise ne koriste i niko nece njima biti zaduzen). Ista prica vazi i za koncertne karte i za karte za voz i za skoro sve ostale sisteme, tako da nista od ovoga nema veze sa ovom raspravom.
Za fisklani racun stvarno ne znam, ali sve i da mora da bude sekvencijalan on to mora biti na nivou fiskalne kase tako da opet nemas nikakav concurrency i ne trebaju ti nikakvi lockovi. Neverovatno je koliko aplikacija funkcionise suboptimalno zbog resavanja svih problema upotrebom pesimistickog lock-a i gde mora i gde ne mora, to sto zablokiras celu firmu dok ti odsviras svoju skrpiticu to nije vazno, radi super na testiranju. Bar da je zbog necega nego zbog generisanja kljuceva i izmisljanja tople vode.
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
Re: ADO.NET i izdavanje racuna
Re: ADO.NET i izdavanje racuna
Re: ADO.NET i izdavanje racuna