Hirdetés

Keresés

Új hozzászólás Aktív témák

  • bambano
    titán

    Fix számú, jelen esetben 3 fajta termék kategória van. Nem is várható bővülés, max jóval később talán 1-2 legfejjebb. Ez a 3 fajta termékkategória összesen 5 mezőben egyezik és minden egyébben különbözik. Ebben az esetben sem volna kényelmes inkább 3db külön-külön tábla? A lekérdezések gyorsabbak és egyszerűbbek lennének.

    "Nem is várható bővülés": híres utolsó mondatok :P

    a lekérdezés sebessége egyrészt nem számít akkor, amikor elméletben vizsgálsz egy logikai struktúra->tárolási struktúra leképezést, másrészt nem is tudhatod előre, mi a gyorsabb, harmadrészt oldja meg a hardver :)

    szerintem a kód mindenféle részén folyton azt mókolni, hogy most melyik táblát kell joinolni, hova mit írsz, az nagyobb teher, mint berakni egy táblába, indexelni, a többit oldja meg az adatbáziskezelő meg a beszerzési osztály rambevásárló felelőse. :)

  • Drizzt
    nagyúr

    Fix számú, jelen esetben 3 fajta termék kategória van. Nem is várható bővülés, max jóval később talán 1-2 legfejjebb. Ez a 3 fajta termékkategória összesen 5 mezőben egyezik és minden egyébben különbözik. Ebben az esetben sem volna kényelmes inkább 3db külön-külön tábla? A lekérdezések gyorsabbak és egyszerűbbek lennének.

    Még egy aspektust akarok felvetni. Milyen táblákhoz kapcsolódik a termék még? Ha van olyan, ami termék ID-t használ, akkor innentől kezdve abban a táblában ha akarsz foreign key-t használni, akkor kénytelen leszel 3 különféle oszlopot felvenni. (Utóbbit mondjuk úgy is ki lehet küszöbölni, ha minden 1:1, 1:n kapcsolatot is kapcsolótáblával valósítasz meg, mintha n:n lenne, mert ilyenkor a foreign key a kapcsolótáblába kerül át.)

    Másik dolog amit fontolj meg, hogy érdemes lehet Flywayt, vagy Liquibase-et használni, ami jelentősen meg tudja könnyíteni az életed, ha később mégis kell változtatni az adattáblák struktúráján, s ilyenkor a meglevő rendszerek update-elése automata kell, hogy legyen.

Új hozzászólás Aktív témák