locked
táblák kialakítása rugalmas termékadatokhoz RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    sziasztok!

    Hogyan érdemes kialakítanom a táblákat olyan szituációban ahol a legkülönbözőbb tulajdonságokkal rendelkező termékekről kell tárolnom adatokat?
    pl.:
    monitor: gyártó, méret, válaszidő
    mosógép: energiaosztály, teljesítmény, centrifuga fordulatszám

    arra gondoltam lesz egy termekek tabla ami csak a minden termékről tárolandó egységes adatokat tárolja id, név, ár, leírás és hasonlók tovább lesz egy termek_adatok tábla ahol lenne termek_id (idegen kulcs), tulajdonsag, tulajdonsag_erteke

    innen lennének kikereshetők az adott terméket jellemző információk. a kérdésem az, mennyire elfogadható megoldás ez? hogyan szokás kezelni a hasonló problémákat? nem lehetne ennél egy a szervert kevésbé terhelő megoldást kieszelni?


    • Moved by Othorvath Saturday, January 16, 2010 2:42 PM (From:Altalanos SQL kerdesek)
    Friday, October 12, 2007 11:39 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    hat nekem igy este, edzes utan 2 megoldas jut elbol az eszembe:

    szelesebb tabla, benne a fix mezok es egy TermekTipusId valamint Attr1... Attr30 mezok (varchar(..) tipussal pl)

    egy masik tabla irja le, hogy adott TermekTipusID eseten az Attr1...Attr30 mezok mit is tartalmaznak

     

    a masik lehetoseg, hog nem ebben a tablaban vannak az Attr1..30 mezok hanem a fotablaban maradnak a fix adatok + TermekTipusID es egy masik tablaban a TermekID, AttribId, AttribErtek (varchar(..)) mezok valamint itt kell a TermekTipusID hoz a leiro tabla, hogy myilen attrbibutumok is vannak hozza, ugy mit az elozo verzional

     

    ket elteres van a ketto kozt:

    sebesseg es tarhely. az elso gyors de soka hely kell neki, a masik lassub de kisebb hely kell neki.

    az elso akkor lehet jo, ha KB azonos mennyisegu attribja van a termekeknek (pl 8-12) vagy ha nagyon szamit a sebesseg

    a masodik akkor jo, ha nagy a szoras az attribok szamaban  (pl 2-12) vagy ha jobban szamit a helyfoglalas.

     

    a 2. verzional meg kcisit macerasit, hogy a sorokbol a feluleten esetenkent oszlopot kell csinalni am SQL verzitol fuggoen lehet egyszeru vagy kevesbe egyszeru Smile de mindekepp munka es ido igenyesebb, viszont jobban boviteheto

    (pl ha 15 attrobit csinalsz es jovore jon egy cucc 16-tal, akkor az elso verziot nehezebb boviteni 16 attribosra, a 2.nal ez nem gond.)

     

    persze masoknak meg bizti lesz mas design paternje is a dolograSmile

    Tuesday, October 16, 2007 8:31 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Jó az a megoldás, viszont lassú lehet egy kicsit, és fejleszeni is nehéz, de nincs túl sok választásod, mert azt tudod esetleg még csinálni, hogy egy XML mezőben tárolod el az egyéb tulajdonságokat , de az már majdnem ugyanaz a megoldás, mint amit te javasoltál.

     

    Esetleg még igy:

     

    Termek

    ID,Name

     

    Tulajdonsagok

    ID,Name

     

    TermekTulajdonsagok

    TermekTulajdonsagID, (ez itt a primary key mert egy termeknek lehet egy tulajdonsága, de annak több értéke is lehet)TermekID, TulajdosagID,Ertek

     

    Safi

    Wednesday, October 17, 2007 10:22 AM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote

    Kell még egy tábla, mert nem tudod, hogy egy terméknél hányféle tulajdonság lehet.
    Ezért a tulajdonságokat is definiálni kell, hogy milyen paramétereik lehetnek.
    Szerintem jó, három táblával megoldható, még access-ben is simán elmegy. Wink

    Friday, November 9, 2007 9:46 PM