Subject: [JavaTech] EBolt - termékek - tulajdonságok

From: Suhai Gábor <[email-masked]>
Date: Thu, 04 Oct 2001 14:26:43 +0200

Sziasztok!

Bedobnék még egy témát (bár az előzőre sem reagált senki, talán most).

A helyzet az, hogy egy ebolt-szerűséget próbálunk összehozni, és a
legnagyobb problémát az jelenti, hogy hogyan ábrázoljuk/tároljuk az egyes
termékek ezerféle tulajdonságait. Úgy gondolom, hogy ez egy eléggé common
probléma, és kiváncsi lennék a véleményetekre. Nem azt mondom, hogy írjátok
le, hogy ti hogyan csináltátok, inkább trükkökre, ötletekre,
iránymutatásokra lenne szükségem.

Ha esetleg a téma nem erre a listára való, akkor lőjetek le.

Gábor

U.i.: ha igény van rá, akkor természetesen leírom, hogy mi mire gondoltunk

---

From: Török Tibor <[email-masked]>
Date: Thu, 04 Oct 2001 18:14:54 +0200

Hello,

Suhai Gábor wrote:
> A helyzet az, hogy egy ebolt-szerûséget próbálunk összehozni, és a

Szerintem a trukk az, hogy az ember azt csinalja, amit elotte
mar parmillioan:-) Nincs "trukk". Ahol van "trukk", ott pofara eses 
is lesz. A legtobb hasznalatos kornyezetre van egy csomo bejaratott
tervezesi eljaras, az ember fogja a kezere allo darabot,
es hasznalja. 

> U.i.: ha igény van rá, akkor természetesen leírom, hogy mi mire gondoltunk

Lehet, hogy nem artana, bar talan elegendo a problemara koncentralni
(nekem pl. nem volt teljesen egyertelmu a kerdes, az "ezerfele 
tulajdonsag" nem tul specifikus:-)), vagy elobb arrol beszelnenk.

(Persze lehet, hogy tenyleg nagyon off...)

udv: TT

---

From: "Janos Domosi" <[email-masked]>
Date: Thu, 4 Oct 2001 18:55:09 -0700

hi,

Én spec. úgy csináltam az ügyet, hogy egy konfigfájlban meg kell adni, hogy
milyen paramétereket  (képek, szövegek, opciós listák, ezerféle
ár....nyelv...) akarsz felhasználni a termékek szemléltetésére.

Minden alaptípushoz tartozik egy tábla, melyben egy tulajdonság egy sornak
felel meg.
Így kaptam egy olyan megoldást, ami rendkívül rugalmas (erre volt
szükségem), és eléggé erőforrásigényes(DB).

de jól működik.
nézd meg a http://demo.rndsoft.hu -t. Ezen a demón a admin felület
nyílvános, így jobban láthatod, hogy mire is gondolok.

De ha gyors és jól definiált - nagy rendszer kell, akkor ajánlatos az 1.
termék/1 tábla/1sor variáció, ahol ezer oszlop van a tábládban.

csá döme

----- Original Message -----
From: "Suhai Gábor" <[email-masked]>
To: "Java lista 2" <[email-masked]>
Sent: Thursday, October 04, 2001 5:26 AM
Subject: [JavaTech] EBolt - termékek - tulajdonságok

Sziasztok!

Gábor

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

---

From: Suhai Gábor <[email-masked]>
Date: Fri, 05 Oct 2001 07:51:37 +0200

Üdv!

> nyílvános, így jobban láthatod, hogy mire is gondolok.
Ez tényleg jó.

> termék/1 tábla/1sor variáció, ahol ezer oszlop van a tábládban.
Ha jól értem, akkor az ezer oszlop a termék ezer tulajdonságát jelöli,
csakhogy esetünkben nem tudjuk, hogy milyen termékek lesznek és azoknak
milyen tulajdonságai lesznek, ezt majd a felhasználó (eladó) fogja
eldönteni. Egyéb részletekért lásd az előző (vagy a következő) levelemet.

Gábor

---

From: Suhai Gábor <[email-masked]>
Date: Fri, 05 Oct 2001 07:59:24 +0200

Sziasztok!

>> A legtobb hasznalatos kornyezetre van egy csomo bejaratott
Esetleg valami konkrétum?

>> tulajdonsag" nem tul specifikus:-)), vagy elobb arrol beszelnenk.
Itt csupán arról van szó, hogy nem lehet tudni, hogy egy terméknek hány és
milyen fajta tulajdonsága van, ugyanis majd a felhasználó (eladó) fogja
eldönteni, hogy milyen adatokat akar tárolni egy termékrol.

Mi a következore gondoltunk:
A termékek természetesen kategóriákba lesznek besorolva, és a termékek
helyett a kategóriák rendelkeznének tulajdonságokkal. Lenne egy os kategória
(mondjuk Termékek), amely olyan tulajdonságokkal rendelkezne, amely minden
terméknek lehet (ár, gyártó, megnevezés, stb.). A Termékek kategórián belül
lennének további kategóriák (pl. Muszaki cikkek, Élelmiszerek, Ruházat),
amelyek öröklik a szülo kategóriájuk (Termékek) tulajdonságait, illetve
további tulajdonságokkal rendelkeznének, pl. a Muszaki cikkek kategóriának
olyan tulajdonságai lennének, amelyek minden muszaki cikknek vannak, pl.
tápellátás típusa. Aztán a muszaki cikkeket lehet tovább bontani
Szórakoztató elektronikára, Háztartási elektronikára, stb., de mindegyik
kategória csak a rá jellemzo tulajdonságokkal rendelkezne, illetve örökölne
tulajdonságokat a szülo kategóriájától. Aztán amikor a felhasználó (eladó,
adminisztrátor) azt mondja, hogy új terméket akar, akkor csak megmondja,
hogy melyik kategóriába tartozik a termék, és már adottak is a
tulajdonságai, amelyeket már csak értékkel kell ellátni.
Vélemény?

Gábor

---

From: "Janos Domosi" <[email-masked]>
Date: Fri, 5 Oct 2001 10:03:35 +0200

Az öröklodés jó ötlet.

magam is gondoltam rá, de már késon, amikor készen volt a rendszerem
persze láttam késobb a hiányát.

[döme]

----- Original Message -----
From: "Suhai Gábor" <[email-masked]>
To: "Java lista 2" <[email-masked]>
Sent: Friday, October 05, 2001 7:59 AM
Subject: [JavaTech] Re: [JavaTech] EBolt - termékek -tulajdonságok

Sziasztok!

Gábor

---

From: Török Tibor <[email-masked]>
Date: Fri, 05 Oct 2001 19:40:55 +0200

Hello,

> Esetleg valami konkrétum?

Elnezest, nem kodositeni akartam, de meg bennem volt a 
bizonytalansag a kerdeseddel kapcsolatban. Altalaban tartom
gyanusnak a trukkos megoldasokat, az esetek legalabb 99%-aban
elegsegesnek, sot kivanatosnak latom az unalmas, mar-mar 
mechanisztikus megoldast. De azt tisztessegesen megcsinalva
szeretem latni. 

Konkretan:-) Nem tudom, milyen modszertant es eszkozt hasznaltok.
UML, SSADM. Eszkozok, kulonbozo kategoriakbol: Rational, Together,
Argo, Oracle Designer, Sybase Powerbase, akarmi mas. Igazabol majdnem 
mindegy, hogy mit hasznaltok, ha a technologia egysegesen hasznalhato.
Bocs, mar megint szoszatyar voltam, raadasul ismet trivialitasokat
szortam:-)
 
> lennének további kategóriák (pl. Muszaki cikkek, Élelmiszerek, Ruházat),

Uhum, nekem meg mindig nem teljesen vilagos, hogy milyen
mgeoldasra gondoltatok, de azert sejtem. Ezt a kostrukciot 
altalanos formaban valositjatok meg, vagy 
valamennyire specialisan (termek, kategoria, stb)? 

Az altalanos megoldas eseten nem erdemes rogziteni elore egy
hierarchiat (Termek, kategoriak, stb.), mert ugyis felborul.
Ha Termekkel indultok, hetszentseg, hogy legkesobb a 3-ik, 5-ik
ugyfel Termekcsoportbol akar majd indulni, kesobb pedig tobb,
alternativ felso szintu csoportositast ker majd valaki. 
(Termekcsoport, arkategoria, energiatakarekossagi besorolas,
szin, illat, stb.)

Ezert az adatszerkezetnek gyakorlatilag egy valamilyen
adatmodellt kell tudnia tarolni. Majdnem mindegy, 
hogy milyen modellt (hierarchikus, halos, relacios, OO, esetleg 
a COM kilapitott objektum-modelljet), de a kivalasztott modellt 
gyakorlatilag teljeskoruen meg kell csinalni. Ha ez megvan, 
akkor nem okoz problemat, ha esetleg valamelyik megrendelo egy 
teljesen mas, esetleg szokatlan hierarchiat (vagy halot) kivan 
felallitani. Ha nem teljes a modellezesi lehetoseg a programban, 
akkor elobb-utobb bele fogtok utkozni a hianyossagba.

Konkretan::-) Egy hevenyeszett, hierarchikus megoldas,
amely felepiteseben egyszeru, uzemelteteseben koltseges:

Tulajdonsagok(t_id,...)
CsopTulaj(t_id,tulajd_no,t_id,......[ertek]... )

	('tulajd_no' sorszam elkerulhetetlen, mert esetleg 
	ismetlodhetnek	bizonyos tulajdonsagok egy 
	tulajdonsagcsoportban. "ertek" elemi tulajdonsag 
	elofordulasanal kitoltendo.)

ahol 'Tulajdonsagok' egyik attributuma mutatja, hogy o mifele 
tulajdonsag, valamifajta elemi jellemzo, vagy egy osszetett, 
mondjuk ugy, 'objektum', vagy csoport (pl: termek, kategoria, 
csavarhuzo). Ennek a megoldasnak nagy hatranya, hogy nagyobb 
adathalmaz eseten a karbantartasa szinte biztosan hibakhoz 
vezet. (pl. feleslegesen ismetlodo, azonos tulajdonsagok - 
mert aki felvette a tulajdonsagot, nem talalta meg az elozo
elofordulast.) 

Ha nem teljes modellt csinaltok, mar kizarolag specialis esetrol 
beszelhetunk - de ez nem biztos, hogy baj.

Egy alternativ megoldas lehet, hogy kettevelasztjatok a 
feladatot. Megcsinaljatok a UI-t, es csinaltok 
(vagy kerestek) egy alkalmatosnak latszo  feluletet
az adatok eleresere, es ezt kikialtjatok hazi szabvanynak.
Ez ala csinaltok egy valamilyen, elso korben mukodonek 
latszo megoldast. Es minden  alkalommal, amikor valaki 
fellep egy uj igennyel, a felulet "alatt" belenyultok a 
rendszerbe, lehetoleg valamifajta adat-modulokkal 
bovitve a rendszert.

Nem feltetlenul elvetendo ez utobbi megoldas, lehet, hogy 
kevesebb eroforrast igenyel a fejlesztesnel es az 
uzemeltetes soran is.

udv: TT
ui: ha feleslegesen es bosszantoan terjengos vagyok, 
konyorgom szoljatok, nekem is egyszerubb rovid 
leveleket irni:-)