návrh db pro e-shop

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é

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.

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á.

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.

peta:
Dík, nevěděla jsem.

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?

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:
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í. :)