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 ;)