Subject: [JavaTech] Relacios DB - Primary Key kerdese

From: Szitas Krisztian <[email-masked]>
Date: Tue, 2 Oct 2001 12:42:50 +0200

Na akkor megnyitom a a listat az elso levellel.
Folytassuk ott ahol a masik listan abbahagytuk, csak eppen felejtsuk el azt
a szamomra baromira
ellenszenves hozzaallast, hogy a problemahoz ugy allunk hozza, hogy hogyan
NEM LEHET megcsinalni,
hanem ugy hogy, hogyan LEHET.

Ott hagytuk abba hogy egy entitasnak ( j2ee alatt EntityBeannel ) nem kell
feltetlenul az entitas PrimaryKey-enek
es az alsobb retegben levo perzisztencialo PrimaryKeyenek egybeesnie. OODB
eseteben ha jol tudom egyertelmu
a dolog, mert ott minden objektumot egy OID azonosit. De mi van Relacios DB
eseteben?
Viktor azt mondta, hogy o minden sorhoz kulon szintetikus keyt general. 
Pl az Embert a szemelyi szamaval lehet egyedileg azonositani (ez alapjan
Unique), de egy generalt PK-ja van.

Kerdes, hogy miert jo ez? Mikor jo ez?

Elony:

Ha megvaltozik a egyedi azonosito (tipus, hossz, de leginkabb erteke), mert
pl betelipiti egy miniszterelnok
az erdelyieket Mo-ra, es mar nem elegendo az utolso 4 szamjegy a szemelyi
szambol (ami csak 3 vegul is)
az egyediseghez, akkor nem kell vegignyalazni az osszes tablankat, es
updateelni mind az relacios-adatmodellt
(mittomen CHAR 12-rol CHAR 16-ra) + meg az ertekeket is atirni,
hanem ezt egyetlen tablaban el tudom vegezni.

Hatrany:

Mindig ott van az a rohadt join. OODB-nel ez nem szamit, akar tizezerszer is
gyorsabb a relacios db-nel,
de hat meg mindig sajnos a relacios db-k uraljak a piacot. 
Pl: egy egyszeru webaruhaznal, ahol tobb penznemet hasznalhatok, egy
egyszeru viewnal is ahol az
arat ki akarom listazni, es a penznem PK-ja szintetikus, es nem mondjuk az
ISO szerinti 3 betu (HUF, DEM),
ott egybol bejon a join.

Tud valaki meg elonyt es hatranyt?

---

From: "Bognar, Attila" <[email-masked]>
Date: Tue, 2 Oct 2001 19:26:02 +0200 (CEST)

> Tud valaki meg elonyt es hatranyt?
Nem jut eszembe, de ha azt vesszük, hogy az OODB-k esetleg teret nyernek
és fontos szempont lehet, hogy egy tulajdonság ne legyen kulcs (mert a
személyi szám - bár már kihalóban van, tulajdonságnak is tekinthető:
ilyen szempontból ez pont jó példa, hogy lassan tök felesleges
attribútum, és mégis tárolni kell, sőt újabb egyedeket ehhez igazítani),
hiszen ki tudja miként változik a specifikáció hosszú távon (lásd személyi
szám, gondolom kitalálásakor nem gondoltak arra, hogy valamikor nem fog
megfelelni az állampolgárok azonosítására), akkor feltétlenül előny
lehet egy mesterséges kulcs.

Nem ismerem az OODB-eket, csak azt hallottam róluk, hogy rosszabb a
teljesítményük az RDB-khez képest (igaz, régi hallomás), persze kérdés,
hogy miben (egy komplex objektum és attribútumainak lekérdezésével biztos
hatékonyabb).

attila

---

From: anemeth <[email-masked]>
Date: Wed, 03 Oct 2001 09:06:04 +0300

Sziasztok!

EJB modulokat kellene terveznem, de kisebb dilemmam van. :)
Eddig akarhol is neztem peldakat, csak olyat lattam, hogy egyik EJB
hivta a masikat. Tudomasom szerint ez RMI call, szoval nem mindig
a leghatekonyabb.
Van e arra lehetoseg, hogy "normal" modon tervezzek meg egy modult,
aminek vannak EJB komponensei es normal java osztalyai.

PL:
FileListener - EJB (bahonnan hivhato kell hogy legyen)
String directory
fileListener(String dir)
checkNewFile()
startProcessingFile(String fileName)

FileProcessor - (normal class, implements Runnable)
String fileName
char status
fileProcessor()
run()
processFile()
writeRecord(String record)
setInProcess()
setProcessed()
setFailed()

carBean - EJB (mas EJB modulok is hasznalhatjak)
carBean()
store()
read()
findByPrimaryKey()

Ez mukodo megoldas lehet? Egybe kell csomagolni a normal classokat
az EJB-vel?

Elore is koszi.

Udv,
   Ban

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Suhai Gábor <[email-masked]>
Date: Wed, 03 Oct 2001 09:55:47 +0200

Sziasztok!

Tervezési szempontból szerintem elegáns megoldás a mesterséges kulcsok
használata, de az említett két példában (személyi szám és pénznemek) túl
nagy az overhead (join) az esetlegesen elérhető előnyökkel (mi leszünk a
leggyorsabbak a piacon, ha változik valami) szemben. Szvsz olyan területen
lehetne ezt jól alkalmazni, ahol gyakrabban történik változás, mint ahogy a
személyi számot vagy a pénznemek jelölésére vonatkozó szabványt
változtatják. Tudom, tudom, hogy 640K mindenre elég lesz, meg Y2K, és
félreértés ne essék nem azt az oldalt képviselem, hogy hogyan nem lehet
megoldani valamit, de a vevő az úr és ha ő azt mondja, hogy lassú, akkor
magyarázhatod neki, hogy milyen jó lesz, majd ha megváltoztatják a személyi
számot.
Összefoglalva tehát jó dolog a mesterséges kulcs, de szerintem csak olyan
területen, ahol egyensúly van az overhead és az előnyök között. (ide most
valami példa kéne, de nem megy)

Remélem nem a lista szellemisége ellen szóltam.

Bennem felmerült egy másik kérdés is ezzel kapcsolatban (lehet, hogy külön
szálban kéne mennie, majd eldöntitek), de mennyi időre kell vagy lehet egy
rendszert tervezni? Mennyire (milyen időtávra) kell előrelátónak lenni?

Gábor

----- Original Message -----
From: Bognar, Attila <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 02, 2001 7:26 PM
Subject: Re: [JavaTech] Relacios DB - Primary Key kerdese

> _______________________________________________
> JavaTech mailing list
> [email-masked]
> http://ebizlab.hit.bme.hu/mailman/listinfo/javatech