Autor Zpráva
novacek90
Profil
Ahoj,
snažím se navrhnout db pro e-shop tak aby to bylo co nejuniverzálnější, ale ani nevím jestli na to jdu dobře.
Takhle na tom jsem v tuhle chvíli.



Tabulka orders je teprve rozdělaná, ale chtěl bych se zeptat jestli by to takhle mohlo být, nebo je to celý úplně špatně.
Popřípadě co by ještě mělo být v takovém návrhu db. Napadá mě už jen tabulka 'reclamation'.

Díky za rady ;)
logging
Profil *
Zdravím,
máš tam par věcí špatně:

1) mezi Clients a Register tam má být spíše 1:1 a nebo 1 registrace může mít několik klientů?
2) to samé mezi items a category. Pokud ti stačí, že věc je v jedné kategorii, tak v tabulce items díš ID_category jinak udělat vazbu n:n s mezitabulkou. takto navržené to má chybu:
příklad: budeš chtít kategorii Auto, tak vezměš a pro první záznam z items uděláš v category záznam s názevm category_name=Auto a k tomu přiřadíš item_ID. Jak potom přidáš další záznam z items do kategorie Auto ?

3) návrh tabulky orders je úplně špatně je to navrženo ta, že máš jedno ID objednávky a v tom máš jednu věc...to asi nechcěš ne? uděláš tabulku orders_items, kde budeš mít ID,ID_orders a ID_items. V tabulce orders nechas ID a client_ID

Snad je to srozumitelné
novacek90
Profil
logging:
1) mezi Clients a Register tam má být spíše 1:1 a nebo 1 registrace může mít několik klientů?
to jsem udělal abych mohl případně řešit odeslání na jinou adresu ale když nad tím tak přemýšlím tak je to blbost takhle
jinou adresu bych tedy měl řešil v jiné tabulce nebo připsat do stávající?

2) to samé mezi items a category. Pokud ti stačí, že věc je v jedné kategorii, tak v tabulce items díš ID_category jinak udělat vazbu n:n s mezitabulkou. takto navržené to má chybu:
příklad: budeš chtít kategorii Auto, tak vezměš a pro první záznam z items uděláš v category záznam s názevm category_name=Auto a k tomu přiřadíš item_ID. Jak potom přidáš další záznam z items do kategorie Auto ?
s tím máš naprostou pravdu jak udělat mezitabulku??


3) návrh tabulky orders je úplně špatně je to navrženo ta, že máš jedno ID objednávky a v tom máš jednu věc...to asi nechcěš ne? uděláš tabulku orders_items, kde budeš mít ID,ID_orders a ID_items. V tabulce orders nechas ID a client_ID
OK

jdu to po upravit ;)


Nejsem si jist ale vytvořil jsem toto



nevím jestli jsem dobře pochopil tu mezitabulku (protože tím pádem v tabulce category je item_id úplně zbytečně ne?)

Ty jiné adresy tedy mám řešit ve stávající tabulce nebo v nějaké nové?

Díky
peta
Profil
Proc pojmenovavas hlavni klice jkao id a ne treba client_id? Pak bys mohl spojovat pres a.client_id=b.client_id a vedel bys, ze se jedna o stejny sloupec.
Proc mas jmeno, heslo, mail vyvedeny zvlast a v tabulce clients to mas napojene na client_id? nemelo by to byt register?
A jak bys to resil, kdybys ted dostal za ukol, ze mas uzivatele v ldap, kam se prihlasi pres user, pws. Zadny dalsi udaj tam neni? Musel bys udelat tabulku user: user_id, user_name. Pak bys udelal tabulku pro role a pro dalsi udaje. Tak by mohl mit jeden uzivatel vice roli a vice udaju pod sebou napsanych.
Adresa je soucasti objednavky. Muze byt pro kazdou objednavku jina. Jednou si to objednavam na firmu, podruhe domu pod stromecek a potreti to zasilam babicce do Podebrad.
Tori
Profil
clients.client_id by se mohl jmenovat spíš register_id. category.item_id je tam opravdu zbytečně. Vazební tabulka class by se spíš měla jmenovat items_categories (podobně jako vazební mezi zbožím a objednávkou).

K objednávkám: V tabulce orders mi chybí hlavně: datum vystavení, datum uzavření objednávky (zaplacena a dodána), aktuální stav (můžete řešit buď jako typ ENUM, anebo flexibilněji přes samostatnou tabulku a jen odkázat na ID stavu), celková cena objednaného zboží. Případně stavy objednávky můžou mít samostatnou tabulku orders_history, kde bude ID objednávky, stav (řetězec nebo ID) a datum - tím pádem budete moci sledovat historii objednávky, kdy byla objednána, kdy zaplacena, kdy expedována atd.
K adresám: můžete mít buď adresy na dvou místech (u uživatele + u objednávky), anebo je všechny dát do samostatné tabulky. V tabulkách clients i orders byste jen přidal ID adresy. Menší redundance dat a nemusel byste prohledávat celou (zřejmě dost velkou) tabulku objednávek, abyste nabídl zákazníkovi poslední použitou doručovací adresu. Adresy dodavatelů nevím, asi bych je nechala kde jsou teď. U adres zákazníků by taky měly být sloupce pro IČO a DIČ, abych mohla objednat na firmu.
V tabulce orders_items by měla být jednotková cena, za kterou bylo zboží objednáno (nelze číst z tabulky zboží, protože se mohla použít nějaká akční cena, slevový kupón, dojde ke zdražení zboží od dodavatele apod.), dále počet kusů a celková cena za všechny objednané kusy (nemusí to být vždy jednotková cena krát počet kusů, jsou např. množstevní slevy).

Ještě případně by se mohla tabulka register jmenovat users, s vazbou na client 1:0...1. Tím pádem by bylo zřejmé, že neslouží jen na uložení registračních údajů, ale že ne každý uživatel je zároveň zákazníkem (např. admin + brigádníci pro doplňování zboží).

Pojmenování PK slouců mi připadá ok, nechala bych na nadřazené vrstvě modelu, jak si to vyřeší. Např. v PrestaShopu se u všech ORM instancí používá vlastnost id, přestože v DB se sloupec jmenuje "id_" + název tabulky.


Ještě k těm LDAP, přihlašování pomocí účtu na FB, gmailu, čipem v ruce apod. - asi by se mi nelíbilo, že si nějaký e-shop ukládá v plaintextu moje přihlašovací údaje k e-mailu aj. Ale jestli se těm službám dá místo heslo poslat jen hash, tak dejme tomu ok. Ale stejně si myslím, že se to má řešit jako další autentikační třída/modul a jednorázové zadání jména a hesla, které si aplikace nikam neukládá.
peta
Profil
Tori: K ldap. Heslo tam nemam, nepotrebuji, to resi prave ten ldap modul. Pouze potrebujes jmeno a id. Jmeno proto, abys ho mohla spojit s id a id pro ostatni tabulky, aby se rychleji vyhledavalo.
Tori
Profil
peta:
Dík, nevěděla jsem.
novacek90
Profil
peta:
Proc mas jmeno, heslo, mail vyvedeny zvlast a v tabulce clients to mas napojene na client_id? nemelo by to byt register?

Jsem právě nevěděl jak vyřešit to, když si někdo objedná tak aby se "registroval" i když nechce a to tak že bych mu na mail odeslal včetně objednávky jeho mail s vygenerovaným heslem, které by mělo nějakou dobu expirace např. týden a kdyby šel nakupovat znova a použil by ten samý e-mail tak bych si ho přiřadil k tomu záznamu v register. A nebo bych si tam zapsal trvalé zákazníky registrované.

Tori:
category.item_id je tam opravdu zbytečně.

to jsem si myslel


Jen připomínám že je to můj první návrh takovéto rozsáhlé db a tedy se rád nechám poučit. A to že v db nemám nějaké sloupce jako jsou např. IČO a DIČ pro nákup na firmu mi je jasné (tohle je jen základ).

Popřípadě neměl by někdo takhle vypracované schéma, které se dá plně použít abych viděl jak je to využito v praxi?
aDAm
Profil
novacek90:
V celé DB máš poměrně dost chyb co se týka dat.

1. Pokud chceš mít možnost vícero adres pro objednávky tak to řeš tak že budeš mít tabulku klientů (clients+register v jednom) a k ní si uděláš v relaci 1:n tabulku adresáře a uživatel si pak v procesu objednávky bude moci vybrat kterou adresu použije.

2. Když vytváříš objednávky tak si udělej dvě tabulky, jednu s objednávkami kde bude jejich číslo, datumy, doručovací a fakturační adresa, prostě vše co se té objednávky týká, aby když vemeš jen tuto jednu tabulku a dáš ji jinam tak abys měl stále info o té objednávce a nedotahoval to z jiné tabulky! Další tabulku pro zboží, objednávky. Zde opět vše o objednaném zboží, jeho jméno, cenu, počet, sleva byla li nějaká atd. Opět ať máš pohromadě data bez nutnosti připojovat další tabulky.

A proč takto je jednoduché, když uživatel edituje svůj adresář tak ti to nezmění data v archivované objednávce, pokud se rozhodneš zboží již neprodávat a nebo přecenit opět ti to nezmění data již v archivované objednávce


Jinak je vidět že si začátečník, co se takhle raději pustit do něčeho jednoduššího a pak to rozšiřovat? Proč musí všichni hned dělat eshopy?
Tori
Profil
novacek90:
neměl by někdo takhle vypracované schéma, které se dá plně použít abych viděl jak je to využito v praxi?
Např. DB schéma PrestaShopu 1.5.
novacek90
Profil
aDAm:
Jinak je vidět že si začátečník, co se takhle raději pustit do něčeho jednoduššího a pak to rozšiřovat? Proč musí všichni hned dělat eshopy?

Máme to jako kolektivní ročníkovou práci. A já jsem dostal návrh databáze ještě s jedním kolegou, ale ten db vůbec nerozumí. Jinak bych se do toho asi nernul (tedy ne teď). Tudíž potřebuji vytvořit nějaký fungující návrh db s minimálním množstvím chyb. To že se to pak třeba upraví je mi jasné ale bylo by špatné hned zpočátku udělat fatální chybu na úrovni návrhu db.

Nejhorší je, že na webu není žádný kloudný postup jak vytvořit optimální návrh.

Tori:
Např. DB schéma PrestaShopu 1.5.

Něco méně složitého bys neměla? :)
Tori
Profil
novacek90:
Tak databáze pro univerzální systém typu PrestaShopu vypadá samozřejmě jinak (tj. složitěji) než databáze pro nějaký konkrétní obchod, byť velký - kromě dat týkajících se zboží se tam ukládají i data pro CMS (např. překlady SEO URL na kontroler+metodu, komentáře a hodnocení zboží, hodnocení zákazníků,...), různé šablony e-mailů apod. Takže by to asi chtělo ujasnit si, jaké vlastnosti ten e-shop má mít, jak moc univerzální ho chcete dělat, jaké vlastnosti má mít zboží:
- kategorie zboží mají jednu úroveň nebo více?
- zboží má různé vlastnosti - některé vytvářejí jedinečné varianty zboží, které lze zakoupit samostatně (barva + velikost, některé mohou mít vliv na cenu), některé jsou společné pro celý produkt (např. materiál) - chcete je rozlišovat?
- ke každému zboží může být přiřazených nula až hodně obrázků
- mají mít svůj obrázek i kategorie?
- může být zboží ve více kategoriích nebo jen v jedné?
- chcete nějak rozdělovat zákazníky (třeba odlišit VIP, kteří budou mít lepší ceny)?
- chcete podporovat více měn/jazyků, a pokud ne, co by bylo potřeba změnit, kdybyste je v budoucí verzi chtěli podporovat?
- různé způsoby dopravy a/nebo platby můžou mít různý vliv na cenu?
- slevy můžou platit pro konkrétní zboží nebo pro vše?
- slevy platí v určitou nastavenou dobu nebo jen sleva zapnuta/vypnuta?
- chcete z nějakého důvodu rozlišovat uživatele administrace a zákazníky?
- která data se mohou časem měnit? Chcete tyto změny uchovávat (např. jednotlivé stavy objednávky)? Potřebujete někde zajistit, že tam budou data, která platila v okamžiku vytvoření záznamu (např. cena zboží v objednávce)?
... a na základě nějaké podobné analýzy navrhnete DB. Pokud se někde rozhodnete, že nebudete tu vlastnost podporovat, tak by stálo za to nad tím aspoň trochu zauvažovat, jakým způsobem byste to řešil (kdyby se vás vyučující ptal/a). O samotném návrhu databáze bude literatury dost, o identifikaci entit a vazeb mezi nimi, úmyslná denormalizace části dat - v tom se IMHO návrh DB e-shopu neliší od návrhu DB knihovny nebo DB obcí ČR. Myslím si, že vám spíš pomůže nainstalovat si nějaký z těch používaných e-shopů (PrestaShop, Magento, OSCommerce,...) a proklikat si trochu administraci a DB schéma, abyste měl lepší představu, co tam všechno může (nebo nemusí) být.

Ale jestli to příliš komplikuju, tak budu ráda, když mě někdo opraví. :)
novacek90
Profil
Tori:
Myslím si, že vám spíš pomůže nainstalovat si nějaký z těch používaných e-shopů (PrestaShop, Magento, OSCommerce,...) a proklikat si trochu administraci a DB schéma

To mě nenapadlo to je dost dobrý nápad díky.
Jinak asi svojí představu se pokusím zredukovat na to nejdůležitější a z toho se budu snažit vyjít.


Díky všem za rady já jdu válčit ;)

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: