MySQL 16 - tvorba databázového systému

proc skoncil tenhle serial.... ????

asi to uz nikoho nebavilo

ert

mate tam mensi kotrmelec, prectete si neco o pouzivani tzv surrogate keys. Mimo id by bylo dobre mit jeste nejaky uzivatelsky klic - treba prezdivku...

..no já syntetické klíče znám:), předně bych chtěl dodat, že o všemožbých klíčích od jednopoložkových k složeným částečným a i syntetických určitě se bavil v seriálu o základech mysql na živě někdo určitě, ale v zásadě jde o používání jedinečné části dat z tabulky coby samostatného jedinečného identifikátoru,  - nesmí se nám v základních datech objevit žádná prázdná ani duplicitní položka - lze tedy použít klíč pro vygenerování pole, které vyjmuté z kontextu nebude mít smysl a slouží k jednoznačnému a pohodlnému identifikování záznamů - pokud tabulka obsahuje přirozený identifikátor, tak se má použít..jenom by mě zajímalo kde v článku je ten kotrmelec:), může mne prosím nasměrovat?:).díky

Kotrmelec je prave ten surrogate key. Pokud by predchazel vasemu datamodelu model konceptualni, tak by k tomu nedoslo... Princip, ktery plati pro surrogate key je ten, ze je nelexikalni - to mate ok / increment..., ale take ze se nema nikde ukazovat (jsou vyjimky - napr viz www.seznamka.cz - cislo inzeratu, ale v podstate je to chyba a ja premyslim o zmene - napr YYMM+sekvence v mesici).

To podstatne proc klic pouzivate je zajisteni integrity dat a odkazy jsou referencni integrita - ta se zajistuje pomoci cizich klicu a nebo triggeru, ktere jeste mySql nepodporuje.

Pokud bych mel dale rypat, tak se pro tabulkyvoli jednotne cislo - v podstate oznaceni tridy - zakaznik, inzerat atd... V odpovedi je lepsi oznacit odpovidajiciho jako odesilatel nebo neco podobneho -* jinak neni jasna role teto polozky v tabulce obdebne v inzeratu - inzerent.

Jeste drobnost - v MySql existuje unikatni klic a tak by bylo mozna dobre definovat unikatni klic nad zakaznikem a cislem inzeratu. Tim zabranime vtipalkum bombardovat nekoho stovkami odpovedi... i podud nechcete toto reseni tak by mel byt unikatni index (Alternativni klic) alespon nad inzerat+zakaznik+datum odpovedi.

A posledni poznamka - lepsi nez tvorit novou seznamku je jit se bavit na tu nasi.

No, máte pravdu:), ale řekněme si na rovinu, a) člověk se požád učí, b) nikdo není dokonalý .. a u návrhů tabulek platí dvjnásob, že by se měly konzultovat s někým dalším, kdybychom na něco zapomněli což je tedy částečně tento případ..a u předchozího dílu seznamky byl náhled na tu vaši a obvykle na úvodu shrnuji, jak produkt lze použít a jaká je u nás situace, to platí i pro seznamky..díky za takovéto komentáře!..

..takže k doplnění:), pokud bychom to číslo inzerátu nechtěli používat pro nějaké identifikování vně, ale měli bychom podle našich tabulek u každého uživatele výpis jeho inzerátů a odpovědí na ně, nebylo by třeba ho veřejně vypisovat a ta hodnota pro posílání meźi dokumenty by byla kódovaná pomocí base64, nevidím v tom problém..ale je pravda, že generovat to ID z více položek by bylo asi lepší, třeba to číslo inzerenta a inzerátů spojit v jeden klíč, to by šlo..

..ale máte pravdu, že 2 uživatelé nemohou mít stejnou přezdívku, takže by nebylo třeba sloupce ID..právě proto by se měly návrhy tabulek konzultovat ještě s někým jiným, něčeho si člověk ovčas nevšimne:)....Díky..

Myslim, ze rozebirani typu polozek v tomto priklade je podruzne. Vice by me zajimalo, jak se autor clanku stavi k tvorbe dokumentace pro web aplikaci.

Je dobre obcas pripomenout databazovym lepicum a nadsenym patlalum libovolnych systemu, ze navrh zacina od myslenky a ne treba od placani obrazovek a formularu, bez znalosti toku dat a struktury databaze.

..dobrý den,

opět bych nejprve odkázal na to, že znalost toku dat jsem v článku zmiňoval a myslím, že proces návrhu systému jsem tentokrát postavil právě na analýzách, sběru dat a myšlenkových postupech:)

..každopádně dokumentace je téma, které tu ještě chybí, a asi bych se mu měl brzo věnovat, samozřejmě je dokumentace na dvě věci:)):

1. Dokumentování zdrojového kódu - kdoliv se v kódu vyzná, i my když se k němu po dlouhé době vrátíme, správné formátován íto zpřehlední.

2. Dokumentace projektu - popíšeme všechny aspekty projektu od postupového diagramu přes tabulky a popis všech dokumentů, funkcí apod.

..pak je tu otázka specifikace projektu..

Osobně mi vyhovuje UML model stavby, dokumentování i specifikování projektu(Together), ale pokud jde o mysql v praxi, asi by se měly ve finále ještě zpracovávat ty popisy tabulek a položek, toho kde se jak s nimi pracuje v rámci těch skriptů apod., nauka dokumentování jako celek se nedá tak jedoduše vystihnout:) a je to náplní vysokých škol vštěpit programátorům jak je důležité je dělat a jak přistupovat k návrhu systémů pokud se nepletu:).

..no tak máte se na co těšit, nachystal jsem na příští díl další pokračování na přání na téma dokumentace - zabývám se organizační, technickou a výslednou dokumentací projektu a asi to celé vydá na dva díly, a to je to ost stručně pojatý a dlouhý:) až hrůza..stačí říct, uvidím jak se vám i ostatním čtenářům strefím do noty..

Toto je opravdu mimo mísu!!! 

..hour soujet:)..nevím jestli je to na mě ale tuším:), takže u diskuse k příštímu článku si můžeme popovídat:)))..

PSC Varchar(15) NOT NULL,
Vek INT,

No nevim, ale takhle se da ulozit i jako PSC napr. "ja nevim".

Proc tam neni int?? Stejne se to musi testovat, ale ma to mensi zaticeni systemu VARCHAR bude mit 5-6 bytu (kdyz to lidi zadaji spravne) a int jen 4B . Nebo jeste MEDIUMINT, ten ma jen 3B

A k tomu veku. Co takhle zadat vek=1600000. To je parada. Vzdyt tam staci TINYINT. 4B misto 1B. Pochybuju, ze nekdo bude strasi jak 200let. No dobry.

Je fakt, ze v malych databazich to nema zas tak velkou cenu, ale zkuste takhle vytvorit databazi alespon o 10*10^6 zaznamu na tabulku a pochopite o cem tady pisu.

No to vase provazani je bezva sekvencni. Co takhle nastavit klice??

V tabulce seznamka_inzeraty chyby podle me KEY(IDZakaznika) a v tabulce seznamka_odpovedi dokonce KEY(IDInzeratu) a KEY(IDZakaznika).

Jeste bych pridal KEY(vek) pro omezeni pri vyhledavani.

A dalsi veci. Zkuste vysvetlit zadavateli, ze ma napsat jako barvu oci text kratsi jak 25 znaku. Vzdyt se to dat upravit taky na ENUM. Takze v maximalnim pomeru 25B na 1B. Tech druhu oci moc neni . A nebo, ze by nekdo napsal "leve oko mam modre a prave hnede"?? Fak super.

A jak je to s adresováním 1 bytu (předpokládám, že o DB se bude starat stroj s CPU o 32 a více bitech. Jak rychle se dá naadresovat 1 B na _liché_ adrese např. na pitomém Pentiu ?

Mimochodem k té barvě očí - existuje určité promile lidí s různými barvami na obou očích.Tak pozor na diskriminaci

Někdy je sice hezké něco předpokládát a podle toho omezit možný vstup do DB, ale jsou situace kdy to zablokuje práci.

Např. v jedné nejmenované firmě (měl jsem v té době dočasně hodnost desátníka) nějaký šikula hóódně nahoře zbastlil program na evidenci zaměstnanců a jejich rodinných příslušníků. Při zadávání údajů se kontrolovalo rodné číslo :

1) na správnost. No budiž. I když jsou určití lidé kteří mají úředně přidělené špatné RČ ...

2) .. a u dětí zaměstnanců se kontrolovalo, aby dvě děti neměly RČ se stejným dnem narození.

Naštěstí to bylo v DBF, takže jsem tam záznamy o těch třech dvojčatech dostal jinou cestou. Po odevzdání jsme byly pochválení jako jediný útvar který odevzdal úplné a správné údaje a já jel na opušťák. Přizat chybu bylo pro autora asi nemožné ....

Ale to jen tak na okraj - není dobré všechno striktně omezovat a IMHO je lepší takové a podobné stavy při zadávání dat kontrolovat, vadná data odmítnout a zapsat je až po potvrzení uživatelem (chybné RČ apod.)

..nevím to jistě, ale myslím že existují i PSČ z písmen, tj. v USA, Itálii a asi všude joinde než u nás a pak taky může do takový seznamky psát amík, ne?:)..u věku asi víc jak 200 mít nikdo nebude:)), ale berte v potaz nárust délky lidského života s horizontem 20 let a podle nových výzkumů si těch 150, 170 let brzo bude moci někdo užívat..a pak tu máme hybernující lidi, kteří se probudí ze spánku třeba po 500 letech:)))..no budiž:)..pokud jde o klíče, máte pravdu:) že bych je nastavil, ale myslím že v části optimalizace jsem to psal resp. zahrnoval do ní, protože klíč/index patří při větších systémech pro vyhledávání k důležitým součástem:)..

blbina

V USA je PSC (ZIP code = "Zone Improvement Plan") NNNNN-NNNN v tomto tvaru (kompletni, tzv. ZIP+4), ale vetsinou se pouziva jenom prva cast pred pomlckou, tj. prvych 5 cislic.

Ta pismenka si asi pletete se zkratkou nazvu statu uvadenou vetsinou pred PSC. Ta ale neni soucasti PSC a muze tam byt i vypsan kompletni nazev celeho statu, nejenom zkratka...

..hleďme, máte určitě pravdu, na obhajobu jen dodám, že nevím jak vy, ale u mě to už nějaký ten rok co sem PSČ používal a do/z ciziny viděl dvojnásob:)..takže by to mohlo být číslo pokud nebudeme chtít celý ZIPcode:)..