Téma: tvorba databází
FORM
offline
65/1937
Hradec Králové
65/1937
Hradec Králové
Vyskytuje se tu někdo, kdo ovládá tvorbu databází? Nejsem si jistej, jak udělat doménový model. Data model už pak odvodím, ale tohle mě dělá problém. Zadání je takovéhle:
„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"?
„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"?
adminmotorkaricz
offline
104/3024
Praha
104/3024
Praha
1 reakcí na tento příspěvek tvorba databází
kdyz je parametru dynamicky pocet s pozadavkem na uzivatelskou administraci, pak je jednodussi pouzit pro vlastnosti jednotne uloziste.
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
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
gnat
offline
7/1402
Praha
7/1402
Praha
1 reakcí na tento příspěvek (reakce na) tvorba databází
Miira> Myslím, že 99% procent webových "programátorů" nehovoří řečí tvého kmene 
Pro vložení příspěvku se musíte přihlásit nebo registrovat.
