Subject: AW: AW: [JavaTech] Relacios DB - Primary Key kerdese

From: Szitas Krisztian <[email-masked]>
Date: Tue, 9 Oct 2001 11:12:04 +0200

Na volt szerencsem tegnap beleolvasgatni a JDO 1.0-as speckoba
(nem rossz, csak meg nagyon hianyzik nekem a prefetching belole)
Megis van valami ebben a mesterseges OID-ben ;-)
A JDO ketfele "primary keyt" hasznal, a specifikacio 5.4.1 es
5.4.2 pontja szerint megkulonbozteti a DataStore Identity-t
es az Application Identity-t (amit mi primkeynek hivunk)
tavabba ir meg non-data store JDO identityrol is, amibe
nem mentem meg nagyon bele.

Visszaterve TT levelere
>Egy kerdes: nem tudom, konkretan mit takar az OID-d. Egy generalt
>valamit (szamot), vagy egy Object-et? Ha szam, a fentiek ervenyesek. 
>Ha Object, akkor ujabb kerdes: miert nem teszed bele a termeszetes 
>kulcsot?

Az oid-vel nem akarok foglalkozni bl, es ui szinten, nem erdekel hogy
micsoda az, mermint egy string egy szam, es azt a perzisztalo reteg
hogyan generalja, ezert egy sima Object.
Ha onhatalmulag belerakom a termeszetes kulcsomat az jo RDBMS eseteben,
de errol a business logic es ui retegekben mar nem kell tudnom,
mert akkor beleesek abba a hibaba, hogy fuggeni fog a teljes appom
attol, hogy mibe perzisztalok. Azt hiszem nem is szabadna kiadnom
a bl fele egyaltalan ezt az adatot.

---

From: Török Tibor <[email-masked]>
Date: Tue, 09 Oct 2001 18:03:44 +0200

Hello,

> attol, hogy mibe perzisztalok. 

A fentiek a ket resze ugyanannak. Ismet az alkalmazott technologia 
miatt vezetsz be egy kulcsot, amit a megoldando feladat onmagaban 
nem indokol. (Legalabbis eddig semmi nem latszott indokolni,
kizarolag az alkalmazott technologiabol szarmaztatott megfontolasok.)

> Azt hiszem nem is szabadna kiadnom a bl fele egyaltalan ezt az 
> adatot.

A business logic elol "eldugni" a termeszetes azonositot 
(ha jol ertem a fenti mondatot) : 
a business logic eredetileg, a valos eletben pontosan a
termeszetes azonositoval dolgozott. Alaposan meg kellene
azt indokolni, hogy egy business logic eljaras, ami egy
letezo, valodi eljarast, vagy annak egy jol meghatarozott 
reszletet kepezi le, miert ne ismerhetne ugyanazokat az
azonositokat illetve azonositasi modszereket, mint a valos
eletben zajlott eljaras. Ha ez az indoklas valoban alapos,
akkor viszont az adott ugymenet eredetileg hibas volt, 
tehat azt is meg kell valtoztatni. 

Ha az egyeb kovetelmenyek miatt megis tarolnod kell valamifajta 
mesterseges azonositot, tul a technologiai korlat beszivargasanak 
dokumentaciojan, egy dolgot semmikeppen nem szabad kihagyni: 
mivel ez egy alternate key (nem csak rdbmsen, hanem barmely, 
azonosito->azonositott kapcsolatot megvalosito eszkozben), 
feltetelenul gondoskodni kell az eredeti, termeszetes azonositora 
vonatkozo megszoritasok (nem ures, egyedi ertek) ervenyesiteserol, 
termeszetesen adattarolas (akarmilyen db) szinten. Ha ez megvan, 
akkor tobbe-kevesbe nyugodtan alhat az ember. De ha kimaradt 
(mondjuk azert, mert az alatta levo tarolo szerkentyu nem kepes 
biztositani ezeket a felteteleket), akkor mar nem az a kerdes, 
hogy elromik-e valami az adatbazisban, hanem az, hogy mikor romlik 
el.

udv: TT