„Jsem majitelem malé autopůjčovny. Máme k dispozici více než 300 vozidel, jejichž výpůjčky potřebujeme sledovat. Zákazníkům nabízíme k vypůjčení automobily nebo motocykly. Každý z nich má své typové označení (např. Škoda Octavia, …) a kategorii (např. malá, střední třída, velká, luxusní, velkokapacitní, …).
Každý typ vozidla je k dispozici ve více exemplářích, každý exemplář má své identifikační číslo (SPZ).
Zákazníci si často půjčují auto podle typu převodovky, někteří upřednostňují ruční řazení, jiní automatickou převodovku. Pro některé je důležitý pohon na všechny čtyřkola nebo barva vozu.
Naše autopůjčovna má hodně zákazníků, z důvodu bezpečnosti si dopravní prostředek může zapůjčit pouze registrovaný zákazník. U každého zákazníka evidujeme jeho jméno a příjmení, telefonní číslo, adresu, číslo dokladu totožnosti (občanský průkaz nebo pas). Každý zákazník má své unikátní zákaznické číslo.
Sledujeme jaké vozidlo má zákazník v současné doběvypůjčeno. Každý zákazník si může půjčit najednou více dopravních prostředků. Je pro nás velmi důležité, aby byla zachována historie všech výpůjček. Pro každou výpůjčku musíme znát datum/čas výpůjčky a datum/čas vrácení vozidla. Protože vozidla zapůjčujeme na různě dlouhá časová období, potřebujeme zvlášť zaznamenávat údaj, kdy se má vozidlo vrátit.“
Došel jsem k tomu co mám dole. Nevím jak si poradit s vozidly. Jestli udělat jen "Vozidlo" nebo udělat hned "Auto" a "Moto"?
1 reakcí na tento příspěvek tvorba databází
steve4ever- Pokud to chapu, tak udelat "vozidla" a k tomu pres FK "ciselnikAuto" a "ciselnikMoto" ve kterem by byly atributy(objem, atd.)?
Tbl[TYP] (ID_TYP,NAZEV) (auto, moto, náklaďák, přívěs,kolo...)
Tbl [TRIDA] (ID_TRIDA,NAZEV) (třída auta)
a tak dále... jak už je tu napsaný - osobně bych použil nějaký číselník vozidel, kde by byly konkrétní údaje a několik dalších číselníků s typem, třídou, převodovkou..... atd... v podstatě záleží jen na tobě, jak moc to chceš mít učesaný.. tvoření tolika na první pohlet zbytečnejch číselníků se zdá hrozný, ale jak je budeš mít vytvořený, tak veškeré úpravy a vůbec celková práce s nimi je daleko lepší, než to mít všechno v jedné tabulce...
1 reakcí na tento příspěvek tvorba databází
Pak to vyfiltrujes na vsechny vozidla, co maji VehicleType ten a ten..
Tabulka Vypujcka s FK na zakaznika a FK na vozidlo.
Zakaznik a vozidlo muzou mit pak odkazy do Slev (za stari auta, za vracejiciho se zakaznika) :D at to neni jednoduche :D :D
Muzu se jen tak ze zajimavosti zeptat v cem bude frontend/gui?
FORM píše: Dík moc Udělám to přes to vozidlo. Uvidíme jak to zhodnotí
steve4ever- Pokud to chapu, tak udelat "vozidla" a k tomu pres FK "ciselnikAuto" a "ciselnikMoto" ve kterem by byly atributy(objem, atd.)?
jak ti radi Slam, vytvor si zakladni tabulky a v ni zaloz atributy, ktery se ale budou odkazovat na jiny tabulky (ciselniky). Udelej to u vseho, treba i u barvy vozidla: napr. Vozidlo.Barva je FK, ktery odkazuje na tabulku Barva.Id coz je PK (Vozidlo.Barva=Barva.Id).
Sice je to na prvni pohled komplikovanejsi, navic i sql dotazy budou slozitejsi nez kdyz vse spoustis nad jednou tabulkou, ale budes mit tu DB pripravenou na pripadny upravy a hlavne pokud budes potrebovat pridat nejakou hodnotu ciselniku (nova barva), vzdy upravis pouze ciselnik. A v pripade potreby rozsireni o dalsi polozku (prvni majitel), zase pridas separatni tabulku (ciselnik) a do hlavni tabulky Vozidlo pridas pouze atribut, ktery na ciselnik odkazuje. Jinymi slovy, predejdes problemum do budoucna
1 reakcí na tento příspěvek tvorba databází
2 reakcí na tento příspěvek tvorba databází
Jinak jsem pro jednu tabulku pro vozidla se vsema parametrama , jednu tabulku zakaniku a jednu tabulku vypujcek kde pouzijes v zaznamu pro vypujcku jen id zakaznjika+id vozidla a si za vodou.
1 reakcí na tento příspěvek tvorba databází
je za vodou do okamžiku, kdy bude chtít např. statistiku, kolik zákazníků si půjčuje červená auta, protože v jednom řádku bude mít 'červená', v druhým '_červená', třetím 'červená_' a čtvrtým '_červená_' (místo _ si dosaď mezeru)
a proč by chtěl takovou hle nesmyslnou informaci? třeba proto, aby se při nákupu novýho auta rozhodl, který se půjčuje víc?...
co se týká licencí za OS - předpokládám, že je to pro firmu a na stanici běží víc věcí než jen tohle, takže jen kvůli tomu bych licenci za OS považoval za bezpředmětnou.. např. existuje účetnictví pod linuxem? to nevím - neviděl jsem moc firem, kde by jeli na na něčem jiném, než MS...
limit connection - záleží na tom pro kolik uživatelů by to mělo být..
Slam píše: steve4ever> nenapsal bych to líp...
neb z vlastních zkušeností vim, ze nejhorší je po nekom opravovat blbe navrzeno DB a migrovat z ni data. Ten cas ted na začátku pri tvorbe mu usetri spoustu casu a nervu v budoucnu...předpokládám, ze data bude mit pro dlouhodobější uziti
1 reakcí na tento příspěvek (reakce na) tvorba databází
gugo píše: Jinak jsem pro jednu tabulku pro vozidla se vsema parametrama , jednu tabulku zakaniku a jednu tabulku vypujcek kde pouzijes v zaznamu pro vypujcku jen id zakaznjika+id vozidla a si za vodou.
no fuj Na jednoduchy selecty mu to stacit bude, ale co slozitejsi dotazy? A co pripadny rozsirovani atributu do budoucna? Pravidla architektury hovori jasne...mit hlavni tabulku a ta pouze odkazuje na ciselniky pres FK. Drzel bych se toho
btw: ma to jeste jedno plus...eliminuje to chyby uživatele pri vkladani dat. Zada blbe barvu auta, misto "cervena" zada "cerena" a pak se mu pri selectu tahle polozka nezobrazi. Kdezto to v pripade číselníku nehrozí, maximalne bude uživatel barvoslepej a misto cerveny vybere purpurovou
Naposledy editováno 22.10.2013 11:59:09
steve4ever píše: no fuj Na jednoduchy selecty mu to stacit bude, ale co slozitejsi dotazy? A co pripadny rozsirovani atributu do budoucna? Pravidla architektury hovori jasne...mit hlavni tabulku a ta pouze odkazuje na ciselniky pres FK. Drzel bych se toho
btw: ma to jeste jedno plus...eliminuje to chyby uživatele pri vkladani dat. Zada blbe barvu auta, misto "cervena" zada "cerena" a pak se mu pri selectu tahle polozka nezobrazi. Kdezto to v pripade číselníku nehrozí, maximalne bude uživatel barvoslepej a misto cerveny vybere purpurovou
N odobra do DB vam kecat nebudu, jsem systemak a programuju jen z nouze a hlavne to tvorim az kdyz programuju, tak nejak nezvladam si sednout namalovat si model a vyvojovej diagram. Sice si myslim ze na takovouhle "mini" vec jsou siselniky zbytecne a ze chybu uzivatele neeliminuje nic.
Ale stran provozu nevim kolik ma limit IIS na win7 ale na xp je to dost zalosne malo. Takze pokud vemes v uvahu ze si tam otevre kazdej klient tak 4-6 connections tak myslim ze na 5-6 ti lidech je slus.
2 reakcí na tento příspěvek (reakce na) tvorba databází
FORM píše: gugo> Tenhle semestr musíme dělat v MS... Druhe mozne zadani byla videopujcovna s 3000 filmy.
Jo to je semestralka smele do toho papir snese vsechno
Nejlepsi obslehnuti semestralky byl produkt UFON .
btw: mate tam v pristim semestru neco jineho nez MS , treba oracle nebo nejakou OS technologii ?
1 reakcí na tento příspěvek tvorba databází
steve- chyba u mě zapomnel jsem to tam napsat. Budu to delat pres ty ciselniky, je to fakt asi nej reseni. :)
1 reakcí na tento příspěvek tvorba databází
Pri vyhledavani staci do entity vozidlo doplnit fulltext sloupec ve kterem se vyskytuji hodnoty treba ve formatu p1c1 (parametr ID1, ciselnik ID1) ktere se pak snadno vyhledavaji formularemm, kde jsou ve chvili vypisu zname id cisleniku i id parametru - volim z tabulky ciselnik id1 pro parametr id1 a vyhledani probehne na vozidlo sloupec s fulltextem "+id1p1" cimz dostavam vsechna vozidla majici prirazenu hodnotu ciselniku daneho parametru. Pro vice parametru se dotaz rozsiri "+id1p1 +id2p1". U parametru je dobre evidovat jestli je vlastnost jen jednou nebo je mozne ulozit vice hodnot parametru - tady ale nevim kdy by se to hodilo, to spis v eshopu kdy si muzu zvolit variantu (barvu,velikost) dane entity.
Je to mozna alternativa pro hodne parametru. Pokud jich je nizky pocet, tak neni treba resit a je mozny udelat pro kazdy parametr vlastni tabulku. Je pak ale komplikovanejsi administrace, kdy se pro kazdou tabulku musi delat sprava :) Kdyz je system rozahlejsi a jednotlive parametry jsou samy dulezite tabulky slouzici jako cizi klice, tak je vyhodnejsi tyto izolovat do samostatne tabulky :) (treba vztah znacka->model kdy je lepsi mit samostatne znacku i model a az ten dat do relace s vozidlem)
Jestli se nekdo zepta jak pak vyhledavat rozsah nebo radit, tak odpoved je takova, ze je nutna pomocna tabulka, kam se data prekopiruji - kazdy parametr, jeden sloupec odpovidajiciho datoveho typu :)
Do odevzdani bych ale toto asi nedaval protoze to je uz dost univerzalni a podezrele :)
Timto navrhem vlastne clovek rika, co bude mozne ve vysledku s daty delat - zadani je stejne celkem obecne a pri samotne realizaci by nejspis doslo k navyseni poctu tabulek...jak jsem treba zminil tu znacku a model kdy tyhle veci musi byt ve vztahu...pro pouhy seznam "Ford Mondeo" to treba neni a da se prohledat fulltextem.
edit: dokazal bych si predstavit evidovat parametry i left/right stromem kdy par_id=0 budou parametry a vsechny potomky hodnoty parametru:) Spoji se tim ciselniky i parametry do jednoho stromu - tohle bych ale nasadil jen v pripade, ze hodnota parametru bude strom. Vyhledavani opet pres automaticky sloupec ktery se plni bud triggerem nebo v aplikaci.
Pisu jen mozne priklady univerzalnosti a divociny :)
Naposledy editováno 22.10.2013 17:19:47
1 reakcí na tento příspěvek (reakce na) tvorba databází
1 reakcí na tento příspěvek (reakce na) tvorba databází
Jestli někdo řešil větší rozsah parametrů nějakého velkého shopu nebo katalogu na obyčejném mysql tak stál taky před výše popisovaným řešením
1 reakcí na tento příspěvek (reakce na) tvorba databází
Naposledy editováno 29.10.2013 11:51:48
Typickým příkladem, kde parametry dominují a můžou být parametry kdy vyberu jeden (barva bílá) nebo více (velikost XL,XXL) je Eshop, nebo katalog zbozi kde kazda kategorie ma jine parametry - dostavam se k 50-200 ruznych parametru...tvorit na kazdy parametr tabulku a ciselnik je pak neefektivni. (nebo kdyz je vyrobim, tak je mnohem tezsi delat porovnavac atd...nehlede na M:N relacni tabulky kterych muze byt treba i 1/3 vsech parametru)
Napadlo me to ve vztahu k entite Auto kde se v case muzou menit parametry aut v zavislosti na pozadavcich zakazniku a technickych parametrech aut ktera jsou k dispozici.
Rozsirim pujcovnu na nakladni auta a bude rozhodujici lozna plocha, ridicske opravneni atd... :)