1 (edited by Lukas 2009-02-17 22:51:25)

Topic: UIID ir DB struktūra

p.s. žioplumas mano, title turėtų būti "UUID ir DB struktūra". Kaltas :(

Pirmas klausimas:

gal kai kam ir kvailai nuskambės, bet... ar UUID ( http://www.ietf.org/rfc/rfc4122.txt ) naudojimas vietoj paprasto bigint turės įtakos užklausų spartai?
Paginde UUID naudojat darant join'us. Teoriškai UUID (128baitai) yra žymiai didesnis už bigint (8baitai), bet praktiškai šiais laikais jau skaičiuojam ne baitai, bet terabaitais.... Savaime suprantama indexai bus naudojami :)





Antras klausimas:
Kadangi eShopai pasidarė gana madingi (kaip anksčiau su one klonais buvo), nusprendžiau ir aš vieną sau susikurti ;)

Taigi kol kas mąstau apie tokią DB struktūrą

Tarkime, kad 'produktas' bus bet kokia prekė, produktas, paslauga, dalykas etc. 1 produktas = 1 UUID tam konkrečiam produktui. Shopas daugiakalbis.


PRODUCTS_GENERAL
id | UUID | last_change (timestamp) | model | status

lenetelė, kur saugo visus naudojaumų produktų UUID + laiko informaciją apie paskutinį bet kurio to prdukto elemento pasikeitimą
model (enum) - norodo modelio tipą - prekė, paslauga etc
status - public /private/draft, gal ateityje ACL?



ROUTES
id | UUID | slug | lang | default (bool)

į tą patį produktą gali vesti keli adresai, jei a) yra aprašymas keliomis kalbomis b) pasikeitus adresui, kad nebūtų nebūtinų negyvų nuorodų netrinam senų įrašų.

O gal geriau kurti atskirą lentelę ancient_roites ir joje saugoti nebegyvus linkus....?



PRODUCTS
id | UUID | lang | title | excerpt | body | authorID | date_create | status

Saugo pagrindinius tekstinius duomenis apie produktą (pagal kalbą)
+ panašus klausimas kaip su routes: noriu saugoti ir ankstesnes teksto versijas (aka revisions) ar geriau viską laikyti vienoje lentelėje, ar naudingiau visus backupus perkelti į kokią ancient_products ?



PROPERTIES
id | UUID | type   | name | param | param_2 | param_3 | param_4| date
2  | ac9.... | price | price | 7.00     //įprastinė kaina 7lt/vnt
9  | ac9.... | price | price | 6.00 | 24 | 6 // kaina, jei perki daugiau nei 24 vnt, pakuotėse po 6
11 | ac9.... | clothing  | size | XXl        // rūbo dydis  - XXl
......

TYPES_OF_PROPERTIES
id | type | title |  description | group | helper | class | order | default

group, order - view'e pagal juos išveda ir rūšiouja eiliškumą (pirma kaina, dydis, vėliau gamintojas, kilmės šalis etc)
esmė, types_of_properties aprašo iš properties lentelės paimtus duomenis, t.y ką koks param reiškia.
helper jei išvedimui reikia kokių nors sudėtingesnių skaičiavimų (pavyzdys su kainos priklausomybe nuo kiekio) nurodo papildomos php funkcijos pavadimimą, kuri visa tai atliks 


veikimo pricipas:

Routes -> routes_general (tikrinam ar pagal UUID ir lang yra chache, jei ne tęsiam) > Products <> properties < types


Aišku vėliau klijuosis visokie reitingai, komentarai etc, bet apie juo vėliau.
Iš esmės, taip aš apsirašiau būsimą projektą, taigi gal turite pastebėjimų, kurioje(iose) vietose šį modelį reiktų keisti, pataisyti?


Thanks ;)

Re: UIID ir DB struktūra

Na man rodos aš skype daug maž viską išdėsčiau ką apie tai manau, trumpai:
a) nematau tikslo naudoti UUID;
b) pradinė struktūrą dar labai skurdi ir reikalauja gilesnės "eshop'o" veikimo analizės, nes čia dar yra per mažas vaizdas kad pasakyti bendrą nuomonę, tiek jau iš karto yra keletas techninių smulkmenų, kurias derėtų taisyti;

Re: UIID ir DB struktūra

o nesinori tau pvz. paimt kokį TVS'ą su produktų katalogu, dailipdyt krep6elį ir būtI laimingam? =]

Su sąlyga, kad šūdo nebus...

Re: UIID ir DB struktūra

Jis nori mokytis ir pabandyti "kažką" realizuoti, o ne atidaryti el. parduotuvę (-;

5 (edited by minde 2009-02-18 13:21:24)

Re: UIID ir DB struktūra

na tada, kaip sakant, pi***s kol jaunas ;]

Su sąlyga, kad šūdo nebus...

Warning: count(): Parameter must be an array or an object that implements Countable in /home/pasokime/domains/mysql.lt/public_html/forumas/include/parser.php on line 820

Re: UIID ir DB struktūra

Ramex paskutine zinute prajuokino :D Pirma karta isgirdau tokia fraze, o tau Lukai - sekmes. :)