pokazao se dosta slab taj njegov increment
bar kod nas pa ga uopšte nismo ni koristili

inače, ova funkcija se može koristiti samo u temp tabelama

bolje napravi neku funkciju u programu,
biće ti mnogo jednostavnije

U kom smislu slaba?
Sta je jednostavnije od deklarisanja polja kao IDENTITY, deklarisanja koraka i povremenog citanja vrednosti sa scope_identity()?

Zasto bi se koristio samo u temp tabelama? Ti mozes uzeti postojecu tabelu (sa hiljadama zapisa ako hoces) dodati mu identity i server ce ti popuniti sve redove ispravno.

Drugo.. Kako moze biti jednostavnije napisati novu funciju koja ce da radi ono sto je vec ugradjeno u server?

I uopšte nije u pitanju funkcija. Ako nisi primetio (a piše velikim slovima u headeru strane), u pitanju je property polja u tabeli.

prva stvar, mislio sam na ovu funkciju



druga stvar
taj identity na tabelama, autoincrement property, smo probali na radu sa složenim ključevima
tipa:

dokument
broj
rbr (identity)

i uopšte nije radio

Identity nema veze sa ključem, već se specificira na nekom polju. Kako misliš "nije radio"?

Pored toga, koja je logika da imaš složeni ključ pored živog identity polja?

gle ovako @jablane
ako se imalo razumeš u normalizaciju baza podataka
onda takva pitanja ne bi ni pitao



poslovna logika u mnogim slučajevima zahteva složeni ključ
pogotovo bankarske i knjigovodstvene aplikacije

naše aplikacije imaju po 2-3 miliona slogova po najvažnijim radnim tabelama
ti podaci se godinama čuvaju zbog prvo zbog analitike, drugo zbog zakona

a da meni identifikator 7 stavke na jednom običnom dokumentu bude broj 123462846323 broj
ne pada mi na pamet

a što se tiče tog propertija

unesi u tabelu koja ima taj property 4 sloga
znaci, dobićeš redne brojeve 1,2,3,4

obriši 4 slog

dodaj jedan slog

dobićeš vrednost 5

znači rupa koliko hoćeš

Jasno, ali sa auto number-om u Access-u (pogledaj prvi post) ces isto imati rupe. Sa druge strane ne vidim zasto bi to bio problem...

ako vi na taj način normalizujete podatke i
ako vam to odgovara, OK

nama to čak ni u osnovnom početku nije odgovaralo

naravno, kad budete išli dalje, recimo kad dodjete do aplikacije koja
radi za 300 korisnika,koja radi na nekoliko baza (MS SQL, Oracle, Interbase, PostgreSQL...),
sve će vam biti jasno

;)

Cak 300 korisnika wow... to je stvarno mnogo...




Hajde molim te objasni mi tu normalizaciju u kojoj je potrebno pored identity polja (koji naravno jednoznacno odredjuje n-torku) imati jos neko polje u primarnom kljucu?

knjigovodstvo
jednoznačna identifikacija dokumenta/stavke

magacin (oznaka magacina)
dokumenat (oznaka dokumenta)
broj (broj dokumenta)
rbr (redni broj)

glavna knjiga, finansijsko
dokumenat (oznaka dokumenta)
broj (broj dokumenta)


Intensa, jel to za banke :)

To sto si naveo su primeri kada treba koristiti realni (natural) kljuc umesto surogatnog (surrogate).

Ne znam da bi iko napisao knjigovodjstvenu aplikaciju u kojoj primarni kljuc cine identity id + broj dokumenta...

Znaci ovde nije rasprava natural vs. surrogate key (toga je bio vec mnogo) vec kako dodati auto increment vrednost u tabelu.


Edit: nije za banke i nije intesa nego Intens (informacione tehnologije novi sad)

Edit: obrisao si post.. pa nema potrebe da moj ostane...

ne skreći temu :)



ako ćeš već razmišljati na taj način
ukoliko implementiraš real ili natural key onda uopšte nemaš potrebe za surogatom

sad lepo svako na svoje radno mesto, tj kući
:)

Bezveze ste zakuvali, a mislim da je odgovor mnogo jednostavniji nego sto bi covek shvatio iz vasih postova... identity radi ONO ZA STA JE ZAMISLJEN sasvim OK.
Da li ce ga neko koristiti za PK... ili cak u kombinaciji sa nekim poljem... niko nije pitao.

a šta ti nije jasno

Znas sta M E N E? Mislim da si u pravu
IDENTETY je nista drugo do naredba SQL Server-u da inkrementalno povecava podatak u datoj koloni. To da li ce se ta kolona koristiti za PK, unque key, biti samostalni PK ili deo kompozitnog, sta god, to je vec problem dizajnera baze.

Uh,
posle 10 godina rada sa MSSQL nisam mogao ni pretpostaviti
da se priča oko identity može toliko zakomplikovati

moje razmišljanje...
obratite pažnju da @@Identity i @@scope_identity nije isto pogotovo u okruženju sa nekoliko stotina korisnika

broju 123462846323 po meni ne fali ništa, pa to je broj za SQL server i važno je da on dobro radi sa njim
a šta developer misli i nije toliko važno, ako ide sve kako valja neće dugo gledati u njega

baza na kojoj sam najviše radio sa grupom ljudi ima oko 5000-6000 strana ugnježdenih procedura
(kada se skriptuju), u 99.99% slučajeva nisu korišteni složeni ključevi, što ne znači da tako treba

nisam nikada imao vremena da tražim rupe u identity koloni, jesu one bitne za nešto?
i o kakvom brisanju to pričate u knjigovodstvu, šta bi sa onim famoznim storno?

300 korisnika je ozbiljan broj, nadam se da ste koristili neki report engine (analysis server)
inače na kraju knjižnog perioda korisnici će "zapucati" server sa izveštajima

PK + Identity is OK, 99.99% mojih tabela ima ovu kombinaciju

Pozdrav

> broju 123462846323 po meni ne fali ništa, pa to je broj za SQL server i
> važno je da ondobro radi sa njim
> a šta developer misli i nije toliko važno, ako ide sve kako valja neće dugo
> gledati u njega

naravno da je tako, samo svaki projektant drugacije radi
kao i ovaj nas

> nisam nikada imao vremena da tražim rupe u identity koloni, jesu one bitne za nešto?
> i o kakvom brisanju to pričate u knjigovodstvu, šta bi sa onim famoznim storno?

niko ih ni nije tražio, niti ce ih tražiti niti su bitne
samo sam napomenuo zašto nama u datom inf. sistemu ne odgovora taj njegov identity,
što ne znači da nije tako

u 80 % slučajeva korisnik hoće sam da unese neki broj zbog nekih tamo trećih stvari
hoće kontrolu nad nekim stvarima, ne nad nekim, nad svim

> 300 korisnika je ozbiljan broj, nadam se da ste koristili neki report engine
> (analysis server)
> inače na kraju knjižnog perioda korisnici će "zapucati" server sa izveštajima

dešava se nekad i ovo
veliki broj stvari nam odradjuje client aplikacija, jer koristimo standardni SQL,
samo za prevlacenje na client, onda client radi obrade i server zato manje opterećen
doduše obrade su malo sporije jer je obrada u prg jeziku,
sva sreca pa je aplikacije Delphi i vremena skroz podnošljiva
a i nije ceo sistem računovodstvo,


> PK + Identity is OK, 99.99% mojih tabela ima ovu kombinaciju

eto, imate sistem koji u kojem vam ovo odgovara


pozdrav

obrada na klijentu me poceća na nekadašnji kliper
ali ako je efikasnije zašto da ne

jel imate neki primer iz prakse za ovo

> obrada na klijentu me poceća na nekadašnji kliper
> ali ako je efikasnije zašto da ne
>
> jel imate neki primer iz prakse za ovo


pa kad radis sa 4 razlicite baze od koje jedna nema uopste trigere,
kakvu bi ti obradu napravio a pri tome smanjio troskove programiranja

ovo vec prevazilazi temu na kojoj se nalazimo,
ako te nesto vise interesuje,
salji na privatne poruke