Pouziti autoincrementu

[Ing. Pavel Janousek]

> -----Original Message-----
> From: Honza Pazdziora [mailto:adelton na informatics.muni.cz] 
> No, mozna si zkuste projit ten thread, zacalo to tim, ze OP hledal
> genericke reseni prenositelne mezi uplne vsim, ja jsem namital, ze
> to neni trivialni, protoze nektere databaze proste autoincrement

	Ano a ja si myslim, ze odpoved pomoci JDBC 3.0. metody je
uspokojive vyrazne vice nez triggery, kdy kazdy dodavatel ma svou
predstavu o syntaktickem zapisu "Procedural language SQL" (existuje
norma?) pripadne neco takoveho jako trigery a stored procedury
neposkytuje jeho reseni vubec (zrovna MySQL myslim je na tom pomerne
uboze). Ano pokud pouzijeme ciste trigery, mame reseni, ktere hledal
puvodni tazatel, ze nejsou vsude je stejne "prijemne" asi jako, ze JDBC
3.0. nema moc implementaci...

> typy nemaji. Jak poznamenal kolega Zak, neni problem napsat si
> triggery tak, aby byl insert na vytvoreni noveho zaznamu ve vsech
> (skoro) systemech stejny ... ovsem stale zustava problem s tim, jak to
> nove id toho noveho zaznamu dostanete zpatky do aplikace.

	Otazkou ovsem je, zda-li to aplikace v tom "atomickem" kroku
vubec potrebuje vedet... - myslim, ze 90% pripadu takovych neni...
Ostatne, jak dostat tyto informace ci je aspon multiplatformove (mysleno
ve smyslu SQL databazi) vyuzivat ma kolega Zak velmi bohate zkusenosti
prave z Mape...

> Samozrejme ze JDBC a stored veci nejsou ekvivalentni vyjadrovaci ci
> modelovaci prostredky, protoze to proste jsou uplne jine veci na ruzne
> pouziti. 

	Jenze "triger" coby modelovaci/manipulacni prostredek
pozadovanou funkcionalitu rovnez nema... a otazka sekvenci je ciste
vendor-specific...

> > potesujici zpravu spatruji v tom, ze nemusim mit 
> vendor-specific reseni
> > na vazby pomoci ciselnych (unikatnich) klicu - casto je to totiz ten
> > primarni (a jediny) pozadavek, ktery zpravidla spluje to, 
> ze pouzijeme
> > cokoli se semantikou autoinkrementu s rozumnou velikosti 
> (coz zase neni
> > tak moc - 2^32-1 - vic ani tuk)...
> 
> Omlouvam se, cetl jsem tyhle radky asi petkrat ale nepodarilo se mi to
> rozparsovat a nalezt v tom zamyslenou semantiku ...

	Pokusim se to tedy rici jinak - ve vice jak 90% pripadu je
jedine vyuziti sekvenci k tomu, ze svazu dve a vice tabulek vazbou.
Sekvence ci autoinkrement je vhodny prostredek, protoze nam zarucuje
dostatecnou entropii v bezne pouzitych objemech - ovsem ta unikatnost -
pozadavek primarniho klice - je velika pouze a jen zpravidla 32-bit uint
=> 2^32-1, coz zase neni az tak moc zaznamu... 

	Ja osobne mam take prirozeny odpor k vazani tabulek pres neco
jineho nez int/serial, ale to z hlediska modelovani neni:

a) vubec pravda
b) vubec potreba

	V 90% vsech tabulek je primarnim klicem (pokud existuje) int,
serial apod., ac nema coby udaj zadny vztah k tabulce ani vazbam... -
samozrejme, ze pres vazbovou tabulku je vhodne modelovat M:N vazby, ale
rucim Vam, ze temer vsechny M:1 nebo 1:N vazby nemusime tvorit pomoci
toho, co tady resime, ale proste jako primarni klic zvolime neco
vhodnejsiho - nehlede k tomu, ze primarni klic muze byt slozeny a presto
ho lze z hlediska modelovani vyuzivat pro vazani s jinymi entitami...

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------