Nejsem návrhář databází, ale celkem dost se v nich hrabu (datamining, analýzy...) Určitě bych šel přes separátní třídu Vozidlo (která bude buď přímo obsahovat všechny, nebo bude navázána na objekty Auto a Moto).

to je na hlubsi analyzu pozadavku, ale urcite by mela byt jedna trida, tabulka "vozidlo" a do ni pridat atribut "typ". Do nej muzes natvrdo umistit nazev (auto, moto) nebo elegantneji se timto atributem pres FK odkazovat na ciselnik Vozidel, kde budes mit ulozeny jednotlive typy. Nejlepsi je mit tabulek podobnych ciseliku vozidel vic a odkazovat se na ne z tabulky "vozidlo". Snad je to pochopitelny

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.)?

Tbl[VOZIDLO] (ID_VOZIDLO,ID_TYP,ID_TRIDA,VYROBCE,MODEL,ROK_VYROBY,SPZ,OBJEM,BARVA,PREVODOVKA)
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...

Taky bych to dal do jedne tabulky, pokud tech atributu nebude moc. Jak pisou ostatni, FK na tabulku "Typ vozidla", kde bys mel polozky jako treba "moto", "osobni",..
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?

Beco> Super . Melo by to byt v MS SQL Server.

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

steve4ever> nenapsal bych to líp...

300 aut v MS SQL ? why ? Tedy je fakt ze jestli to cches v .netu tak sql express je zadara ale stejne budes muset platit za OS.

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.

gugo>

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

Slam> tak to snad neni problem ne "select vypujcka from auta,vypujcky where auta.color='red' and vypujcky.auto_id=auta.auto_id"

Predpokladam ze by to melo bezet na serveru ne ?
Na stanici ti nebude stacit limit connections.

já bych to udělal trochu jinak. Základní entita je Vozidlo, k tomu M:N vazba Vlastnosti. Vlastnosti by měly Typ_Vlastnosti 1:N. Výpůjčky sledovat M:N přes Akce (samozřejmě Typ_Akce 1:N). Ty Vaše návrhy DB znamenají, že když by přišel požadavek na sledování nové vlatnosti (na 100% by během prvních dní přišle požadavek na přidání typ paliva), tak by jste museli předělávat datový model i aplikaci. Já bych jen přidal do Typ_Vlastnosti záznam Palivo a do Vlastnosti Benzin, Nafta, LPG, ... DTTO pro akce. Požadavek na sledování zda je vozidlo např. na servisu by přišel po nasazení velmi instantně, takže do Typ_Akce ke stávajícímu záznamu Výpůjčka přidám jen Servis a můžu vesele evidovat.

gugo> mno.. tak zrovna ten select tak, jak jsi ho napsal veme v ůvahu pouze jednu hodnotu v db... aby vzal všechny, co jsem psal jako příklad výš, musel by tu podmínku mít pod mssql trochu jinak...... where auta.color like '%red%' a v ten moment je v háji, protože, když tam bude mít napsáno, že auto je 'hnědý s dredama' to ho má v selectu taky...

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

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.

gugo> Tenhle semestr musíme dělat v MS... Druhe mozne zadani byla videopujcovna s 3000 filmy.

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 ?

FORM> jako linej ajetak jsem cetl jenom technicky zadani, nevedel jsem, ze to mas do skoly. V tom pripade bych to skutecne radsi udelal pres ty ciselniky, pokud tvuj pedagog rozumi architekture DB

gugo- jojo, další semestr by měl být oracle. Zatím mě to docela zajímá, takže počítám s tím, že budu pokračovat i v dalším semestru. UFon, ten tel. operátor?

steve- chyba u mě zapomnel jsem to tam napsat. Budu to delat pres ty ciselniky, je to fakt asi nej reseni. :)

FORM> JJ ufon to bylo cely postaveny na nejaky ukradeny semestralce i s chybama

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

Miira> Myslím, že 99% procent webových "programátorů" nehovoří řečí tvého kmene

gnat> nikdy bych neřek že ananas bude na celém systému to nejzajímavější a blbý ER diagram znemožní rychlé získávání a záznam dat.
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

Miira> Každá analýza a každý datový model platí max. do předvedení prototypu klientov. Poslední dobou používám na prototypování jen čtyřtabulkové schema (entity, atributy, relace a hodnoty) a datovou strukturu z něj generuju až před finální verzí.

Naposledy editováno 29.10.2013 11:51:48

gnat> jakým způsobem dosáhnu správného cíle je otázka druhá - jen jsem napsal konkrétní příklad jak se dá řešit systém, který má jednu výrazně parametrizovanou entitu. Pokud se k tomuto řešení dostaneš přes 4tabulkový prototyp, proč ne.
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... :)

nevim co přesně máš na mysli, ale něco takovýho...?
pracuješ se SAPem?