Tvorba databází v MySQL - I (diskuse)

[kamenac]

Clanek je dobry, jen me zarazily ony "normovane formulare". Vznikly patrne otrockym prekladem z "normal form" (cesky casto opet mylne prekladane jako "normalni forma").
Spravny preklad je "prvni normalizovana forma".

[Robert Krátký]

moje chyba: autor me na tuto svou chybu upozornil, ale ve shonu jsem ji zapomnel opravit.

[Kocour_easy]

Celkem dobre,ale: 1."Se strukturovanými daty se pracuje mnohem lépe, než s daty uloženými např. v souborech", to mam chapat jako, ze Databaze uklada data nekam do prostoru?? 2.Proc by nemohl byt primarni klic duplicitni??? Dik

[Radek]

ad 1. At uz databaze uklada data kam chce, smysl je prave v tom, ze to nas pri praci s daty v databazi nemusi zajimat a mohu s daty pracovat skutecne tak, jako by byly ulozeny nekde v prostoru

ad 2. Lepe receno hodnota primarniho klice nemuze byt duplicitni. Tato hodnota totiz slouzi k tomu, aby jednoznacne identifikovala prave jeden radek v tabulce. Primarni klic muze byt tvoren i kombinaci vice sloupcu. Relacni model nezna jiny zpusob, jak jednoznacne identifikovat jeden radek tabulky. Proto to tak musi byt a databaze hlida, ze je tato vlastnost splnena.

[xyz]

1. Nie databaza si to tiez uklada do suborov na FS, ale nie ako bezny textovy subor, alebo podobne. MySQL ako aj ostatne databazy to storuje ako binarne data. Napr: oracle to ma tak, vytvoris si tablespace s nejakou velkostou, tento tablespace je vacsinou na zaciatku jeden subor (datafile ulozeny na disku). Samozrejme tablespace sa moze mat viacej data files. No a v tablespace sa sklada este z mensich logickych jednotiek tzv. data segemnts a tie sa skladaju este z mensich, co su extenty (extents), ktore sa postupne tvoria ako sa plni databaza a tvoria sa podla pravidiel, ktore si vies nadefinovat. No a ked sme sa dostali uz sem, tak spomeniem, ze extenty sa skladaju z blokov alebo presnejsie z data blocks. 2. primarny kluc je nieco, co sluzi na jednoznacnu identifikaciu zaznamu a z tohto dovodu, nemoze a nesmie byt duplicitny!

[t0rN]

mluv česky, sakra, jsi na českym serveru!!!

[d.f.h]

t0rN> zabij se, ty nadhero!

[Santa Klaus]

Sa nepotentuj ty pepik!!!

[Richard Gavenda]

Primární klíč je tu od toho, aby jednoznačně identifikoval záznam. Pokud by byl duplicitní, jak pak neleznu záznam se kterým se má pracovat?
Autorovi: skvělý článek, doufám, že kvalita zůstane i v dalších dílech.

[rat]

jen k tomu prikladu s adresou - nejde jen o prehlednost (ta je navic subjektivni), ale i o schopnost reprezentovat data. v tomto konkretnim pripade pred normalizaci "neexistuje" (mysleny) objekt adresa, nedokazu ho popsat pokud na te adrese nekdo z me databaze nesidli a ani pak neni nezavisly. to nemusi ale muze vadit, casto se to ukaze az po nejake dobe a musi se to nejak zaprasit, cimz jde prehlednost zcela do haje. takze doporucuju nehledat v konkretnich pripadech duvody "proc normalizovat", ale naopak "proc nenormalizovat".

[met]

Pekny clanek, doufam, ze casem dojde i k tomu jak pracovat s MySQL z PHP ci Perlu.

[Tomáš Hofman]

Ne, ze bych proti MySQL neco mel (jako, ze mam :), ale zacina to vypadat na hegemonii jednoho (navic pomerne spatneho db serveru), proc taky nekdo nenapise neco o PostgreSQL? Navic podle toho co jsem precetl to neni o MySQL, ale o SQL (ze by skryta reklama? ale to snad ne...).

[Jan Kubik]

pan asi necetl zakladni dila ceskeho guru Karla Zaka na rooto a jinych zdrojich. Stydte se.

[theo]

cesky guru Karel Zak mi neni prilis znamy takze mi neni jasna souvislost. Stydet se nemam za co.

[Robert Krátký]

Clanek o PgSQL se uz mam "na stole". Vyjde doufam pristi tyden. Pak si muzete zaflamovat .

[Zdeněk Burda]

Uz se tesiiim

[buffery]

Ja taky

[pavel 'goldenfish' kysilka]

vydrzte, urcite neco vyjde.

[xyz]

Odkaz pre T. Hofmana Podla coho sudis, ze MySQL nie je dobra databaza? My sme pouzivali PostgreSQL, problemy zacali byt cca u 1GB databazy. Momentalne pouzivame MySQL a momentalna velkost DB je nieco cez 3G a doposial sme nenarazili na ziadny problem s rychlostou. FUD1. MySQL nema transakcie - MA! dokonca pouziva dva typy transakcnych databaz BDB (na tejto je zalozene aj postgre), InnoDB (je rychlejsia a ma kopec vymozenosti oproti BDB). FUD2. MySQL sa nehodi na vacsie projekty, NASA vymenilo Oracle za MySQL na vsetkych weboch. MySQL pouziva aj Yahoo. FUD3. MySQL nepozna subselecty - pozna, 4.1.0, mam ju skompilovanu a ide to super! MySQL nema trigre, ani stored procedury - ano nema, stored procedury sa chystaju a dokonca budu moct byt aj v roznych jazykoch na zaciatok to budu dva nativny (nieco ako PL/SQL alebo postgre bastard PSQL) a PHP, pretoze do MySQL sa integruje ZEnd Engine a neskor to bude C, Perl. Trigre autori nechcu kvoli rychlosti, ale postupom casu aj tak budu donuteny. BTW: na pseudo stored procedury existuju patche do MySQL. FUD4. Z Postgre sa jednoduchsie prechadza na oracle - skusali ste napr. uz migrovat vase stored procedury Na zaver len dodam, ze "milujem" ludi, ktory si niekde nieco precitaju alebo vypocuju na prednaske a zacnu sirit FUD. Pri tom tito ludia ani netusia, co to je full table scan, prip. rollback segment, redo log alebo aky je rozdiel medzi B-tree indexom a bitmapovym indexom a co a kedy pouzit. MySQL je velmi dobry a rychly SQL server a vrele ho doporucujem. Neexistuje najlepsi ani "unbreakable" SQL server, kazdy je na nieco dobry, len je potrebne poznat ich prednosti a slabiny a podla toho postupovat pri vybere pre nejaky projekt.

[Pavel 'Goldenfish' Kysilka]

zdravim,
a pridam si do flame.
1) rychlost je sice hezka vec, ale pokud dana database nema nejake featury, tak si je potom muzete doprogramovavat a jako programator si to opravdu hodite.a o prenositelnosti na dalsi projekty si muzete nechat zdat.
2)subselecty - nevim, jak vy, ale ja bych si nedal na server versi databasoveho serveru, ktera neni poradne ozkousena.
3) funkce a trigery - pokud je znate, tak tam se da teprve rici, ze umite neco s databasemi.a v tom je sila pouziti databasi. ne v tom, ze umite udelat SELECT A INSERT.tento bod nemyslim nejak spatne.
4)pokud je database pomala pri urcitem mnozstvi dat, tak se to vyplati mozna si dat do database nejaka testovaci data.menit potom uz databasovy server je pozde.
5) taky jsem se domnival, ze mysql je to nejlepsi, pred pul rokem jsem zmenil nazor. ale zalezi to od projektu.
zatim goldenfish

[theo]

Co treba View? V MySQL planovane nekde ve verzi 5.?.? Co relacni integrita? Co zabezpeceni integrity dat (uznavam, ze ani PostgreSQL tohle nema dotazene do konce, ale kdyz uz jste nekousl ten Oracle :). Je mi uprimne jedno co pouzivate vy, ale zaujalo me to, ze clanek popisujici SQL ma v nazvu MySQL...

[Michal]

Dobry den, Mam dve laicke otazky. Mozna jsem plne nepochopil ty vazby, ale u finalniho prikladu (3NF) nemohu vycist vazbu na zakaznika. Cekal bych, ze v nejake jine tabulce (produkty, objednavky ?) bude uveden klic ID_Zakaznika. A druhy dotaz. Chapu spravne, ze se u tabulky Dodavatele meni Dodavatel_Nazev na ID_Dodavatele ? Dekuji moc, michal

[David Hauzar]

Diky za objeveni chyby. 1. V prikladu u 2NF i 3NF vazba na objekt Zakaznici skutecne chyby. Objekt Objednavky by mel obsahovat sloupec ID_Zakaznika. 2.Kdyz bychom predpokladali, ze v databazi nebudou dodavatele se stejnym nazvem, mohl by se sloupec Nazev_Dodavatele "zmenit" v primarni klic nove vycleneneho objektu Dodavatele (tj.v ID_Dodavatele). Pokud bychom toto nemohli predpokladat, museli bychom v objektu Dodavatele vytvorit novy sloupec Nazev_Dodavatele (sloupec ID_Dodavatele by pak obsahoval treba nejake u kazdeho zaznamu jine cislo). U prikladu k Kam az normalizovat chyby v objektu Adresy sloupec Adresa (kdyz bychom predpokladali, ze v databazi nemohou mit 2 zakaznici stejnou adresu, mohl by sloupec ID_Adresy obsahovat adresu a mohlo by to zustat i tak, jak to je - situace je podobna jako u sloupce ID_Dodavatele).

[David Hauzar]

Mezi objektem Zakaznici a Adresy by mela byt relace M:N, protoze 1 zakaznik muze mit 2 adresy, ale i 1 adresa muze prisluset vice zakaznikum (spolubydlici). Objekty tedy budou vypadat takto: Zakaznici(ID_Zakaznika, Jmeno) Rozpis_Adres(ID_Rozpisu_Objednavek, ID_Zakaznika, ID_Adresy) Adresy(ID_Adresy) Ve sloupci ID_Adresy bude ulozena adresa. (V tomto pripade nemusime vytvaret zadny novy sloupec Adresa, protoze adresa v sloupci ID_Adresy bude vzdy jina)

[Michal]

Diky. Uz mi to zacina davat smysl ;) m. P.S. Tesim se na dalsi dily.

[David Hauzar]

oops udelal jsem dalsi chybu... v popisu objektu Rozpis_Adres ma byt samozrejme misto ID_Rozpisu_Objednavek ID_Rozpisu_Adres

[vit novotny]

zajimalo by mne zda lze mysql vyuzit bez znalosti programovacich jazyku.. zda lze nejak volat data z mysql do html..treba ze bych mel html stranku a zni bych si cucal mysql data ? pokud ne asi nema smysl se tu zabejvat jen (my)sql a rovnou by to chtelo vzit od podlahy i s nejakym tim programovanim aby clovek potom rovnou mohl neco zkusit udelat.. a ne znat jen 1/2 nutneho.. ..ja bych radeji kdyby tu byla poradna vyuka php v cestine pro zacatecniky nebo programovani C pod linux pro zacatecniky.

[David Hauzar]

Pro programovani www stranek php bez znalosti programovani vyuzit nemuzes. K databazi se potrebujes pripojit a pak ji sdelit, jaka data od ni chces. Databaze ti vrati data a ty musis jejich vkladani do html nejak ridit. Vse se dela pomoci programovaciho jazyku. Pro rychle nauceni doporucuji PHP. Literatury v cestine o PHP je mraky - pro zacatecniky vrele doporucuji: Ucebnice zakladu PHP4 od Grady - ani neni draha - stoji 200 KC. Rekl bych, ze poradna vyuka php pro zacatecniky tady nikdy nebude, protoze to je dost rozsahle a kvalitni literatury v cestine je hodne. Jeden z duvodu, proc jsem napsal tenhle serial je, ze v literature o php je mysql vetsinou probrano jen hodne povrchne a aktualnich, strucnych, prehlednych, v cestine napsanych knih o MySQL neni mnoho.

[Frank]

Mám doma knihu Naučte se MySQL za 21 dní, a přijde mi hodně dobrá. Též mám rád knihu PHP tvorba interaktivních internetových aplikací - podrobný průvodce (J. Kosek). Pak se můžete mrknout i do PHP a MySQL - rozvoj webových aplikací (Luke Welling, Laura Thomson) nebo do PHP a MySQL (Hugh E. Williams, David Lane). Kvalitních knih v češtině je spousta, stručné sice nejsou (to je spíš úloha on-line úvodů a tutoriálů), ale není se co divit. Pokročilý uživatel stručnou referenci nepotřebuje a začátečníkovi je IMHO k ničemu.

[Jan Kubik]

Mam malou prosbu na autora, jestli by nebylo mozno v pristim dile take napsat, proc vubec SQL, co jsou nevyhody, jake existuji alternativy. Do jakych slepych ulicek se napr. zenou projekty, stavici na SQL. Nekdy mam takovy pocit, ze cela programatorska obec akceptuje SQL jako neco od Boha - asi jako kdyz se myslelo, ze Zeme je placata. Povazoval bych za spravne, nez se dalsi generace vrhnou do diskuzi o tom, jestli je subselect potreba ci ne, si udelat jasno, jestli je ta SQL potreba - a jestlize ano, v cem nas omezuje. Dekuji

[Pavel Stehule]

Ac nejsem autor, dovolim si odpovedet. Jsem totiz jeden z tech, kteri do programatorske obce busi nazor, ze SQL je dar od boha (i kdyz mi chvili trvalo, nez jsem se SQL naucil pouzivat, a jeste dyl nez jsem se s nim nejak dusevne smiril). Duvody proc pouzivat SQL jsou podle mne dva: a) radikalne se zjednodusi program, resp "zasmodrchanost" se presune do SQL, b) davam prostor k optimalizaci provedeni dotazu tim, ze problem popisi pomoci SELECTU. Musel bych znat velice dobre konkretni system abych navrhnul aplikaci, ktera bude stejne efektivni jako zoptimalizovane SQL. Kdysi jsem kvuli tomu odmital programovat v MS Accessu, kdy misto programovani se provadela jakasi alchimie. Krome jineho si mohu dotaz odzkouset nanecisto mimo programovanou aplikaci. Dale citelnost SQL dotazu je vetsi nez citelnost ISAM aplikaci (i kdyz jde asi o zvyk). Nevyhoda mi prijde jedina, ve vyjmecnych pripadech mohou byt reseni nezalozene na SQL databazich mnohem rychlejsi. viz rychlost ruznych malych systemu zalozenych na Foxce. Navic znalost SQL se vyplati i proskolenym uzivatelum, kteri at nemusi programovat jsou sto vyzobat z bazi potrebna data a nemusi kvuli tomu otravovat programatory, kteri se mohou venovat bohulibejsi praci, jako je psani nejapnych clanku pro internet:->. Co se tyce funkcionality, pro relacni databaze nevim o nicem co by neslo resit skrze SQL+ulozene procedury. Diskuze o tom, zdali db podporuje vnorene selecty, triggery atd je jen o tom, ze s temito vymozenostmi mohu napsat aplikaci o fous jednodussi, kratsi a pravdepodobne i robustnejsi a spolehlivejsi. Moznosti databaze maji samosebou dopad na navrh aplikace. Pokud databaze neumoznuje triggery, pak mam tenkou db vrstvu a mnohem slozitejsi aplikacni vrstvu (a nemusim tolik rozumet databazim). S triggrama a ostatnima paradickama napisi aplikaci skorem jenom na urovni databaze a vsechno ostatni je vlastne jen uzivatelsky interface. Velice silne a rychle generovani reportu je napriklad databaze generujici XML, ke kteremu se pripoji jen CCS a cele se to posle klientovi. Aplikaci mohu napsat i v tom nejpomalejsim skriptovacim jazyku a neovlivnim tim nijak vykon. Debata SQL ano ci ne uz dneska je pase. Pripomina to casy, kdy se diskutovalo o tom, zda-li je lepsi FORTRAN nebo strukturovane jazyky. NESQL databaze budou existovat stale (pro zvlastni pripady), ale bude to jen zlomek pouzivani db. Navic SQL nebo jazyky na nem zalozene celkem dobre integruji pristup k datovym zdrojum. Skrze SQL mohu odesilat filtrovat a cist maily, sledovat a monitorovat konfiguraci pocitace (WMI), dohledavat soubory, vyhledavat fultextove (FileNET) atd. Pavel

[Jiri Matejka]

Zdravim, rad bych se dozvedel proc jsou casti clanku temer shodne s texty z knihy Naucte se MySQL za 21 dni (vydal cPress, autor Mark Maslakowski)?
Napriklad cely blok o normalizeci databaze vcetne prikladovych tabulek s nazvy sloupcu jsou identicke a texty trochu poupraveny a nektere nadpisy odstavcu uplne stejne...
Nikde ale nevidim, ze by tato kniha byla napsana jako zdroj ze ktereho se cerpalo...
Muze autor dat odpoved?
Diky

[David Hauzar]

Zdroje ze kterych jsem pri psani tohoto prvniho dilu cerpal: Naucte se MySQL za 21 dni, clanek (a jeho komentare) Modelovani databazi ze serveru root.cz, okrajove jeste i z PHP pokrocile programovani pro world wide web.

Jinak na tom, ze jsem pouzil stejnou definici normalizovanych forem, nevidim nic spatneho. Tech definic normalizovanych norem je sice vice, vsechny jsou ale obdoby originalni anglicke.

Cely dil je zalozen na vytvareni databaze internetoveho obchodu. Neni to zrovna originalini reseni (priklad tvorby internetoveho obchodu se dnes vyskytuje temer ve vsech knihah o PHP nebo MySQL), nicmene databaze internetoveho obchodu je prakticky a pro lidi snadno predstavitelny priklad).
Priklad k normalizaci databaze je vytvoren tak, ze se do jednoho objektu z databaze internetoveho obchodu "nacpou" vsechny sloupce z ostatnich objektu (pro prehlednost jsem vybral jen nektere z nich) a objekt se pak pomoci normalizacnich pravidel rozklada. Vim, ze stejne je to provedeno i v MySQL za 21 dni, toto je ale nejlepsi reseni. (samozrejme bych mohl vymyslet na normalizaci priklad nesouvisejici z databazi internetoveho obchodu. Vzhledem k tomu, ze vyuzivam priklad internetoveho obchodu v predchozi casti, nebylo by to tak vhodne).

Nadpisy odstavcu: Odstavec pojednavajici o prvni normalizovane forme se ve vetsine literatury jmenuje Prvni normalizovana forma atd.

PS: Procital jste si uz manual o MySQL? Jiste (by) jste si vsiml, ze v MySQL za 21 dni jsou nektere nadpisy odstavcu identicke a nektere texty temer stejne jako v manualu. Vetsinou totiz nema smysl vymyslet nove definice, popisy funkci apod.

[radan]

tady to snad pujde

[zabi]

zdar

[radan]

jj sem to pujde

[m]

/*1 vytvořte funkce sachta_max(id_trpaslika,mesic, rok) vstupními argumenty jsou id_trpaslika, mesic a rok v číselném vyjádření(rok na 4 číslice), pro které dany trpaslik  zadanem mesici vytezil nejvice kg rudy. pokud v danem mesici trpaslik v zadne sachte netezil, vrati funkce hodnotu null, pokud mel ve vice sachtach stejny max vysledek, vrati funkce zreteteny seznam techt sachat, napr 'u potoka, v chvoji

[m]

/*2 vytvorte pohled trp_max_smen, jehoz vystupem jsou sloupce s nazvy, trpaslik, sachta, pro kazdeho trpaslik z tabulky trpaslici bude v pohledu uvedeno, v ktere sachte natezil nejvice kg rudy v roce 2006 v unoru pokud to bylove vice sachtach budou tyto zretezeny ve 2.sloupce-viz popis predchozi funkce  */
/*3   */

[zabi]

to je pekny teda :X

[m]

/*1 vytvořte funkce sachta_max(id_trpaslika,mesic, rok) vstupními argumenty jsou id_trpaslika, mesic a rok v číselném vyjádření(rok na 4 číslice), pro které chceme vratit nazev sachty, v ktere dany trpaslik v zadanem mesici vytezil nejvice kg rudy. pokud v danem mesici trpaslik v zadne sachte netezil, vrati funkce hodnotu null, pokud mel ve vice sachtach stejny max vysledek, vrati funkce zreteteny seznam techt sachat, napr 'u potoka, v chvoji*/

znova byla tam chyba

[zabi]

create or replace view  trp_max_smen as
select jmeno,sachta from
(select trpaslici.jmeno,sachty.sachta,max(tezby.skutecnost)as pocet from trpaslik.trpaslici
join trpaslik.tezby on trpaslici.id=tezby.id_trpaslika
join trpaslik.sachty on tezby.id_sachty=sachty.id
where tezby.den BETWEEN TO_DATE('01.02.2006','dd.mm.yyyy') AND
TO_DATE('28.02.2006','dd.mm.yyyy')
group by trpaslici.jmeno,sachty.sachta)

[zabi]

 

nejni osetreny kdyz so utreba dve sachty kde ma stejne

[zabi]

RETURN VARCHAR2 AS v_vysledek VARCHAR2; BEGIN SELECT trpaslici.id, trpaslici.jmeno, id_sachty, sachty.sachta INTO v_vysledek, MAX(tezby.skutecnost) FROM trpaslik.trpaslici JOIN trpaslik.tezby ON trpaslici.id = tezby.id_trpaslika JOIN trpaslik.sachty ON tezby.id_sachty = sachty.id WHERE trpaslici.id = in_id_trpaslika AND (TO_CHAR(den, 'MM') = in_mesic) AND (TO_CHAR(den, 'YYYY') = in_rok) GROUP BY trpaslici.id, trpaslici.jmeno, id_sachty, sachty.sachta HAVING MAX(tezby.skutecnost) = (SELECT MAX(tezby.skutecnost) FROM trpaslik.trpaslici JOIN trpaslik.tezby ON trpaslici.id = tezby.id_trpaslika JOIN trpaslik.sachty ON tezby.id_sachty = sachty.id WHERE trpaslici.id = in_id_trpaslika AND (TO_CHAR(den, 'MM') = in_mesic) AND (TO_CHAR(den, 'YYYY') = in_rok) GROUP BY trpaslici.id, trpaslici.jmeno); RETURN v_vysledek; END;

[zabi]

CREATE OR REPLACE FUNCTION sachta_max(in_id_trpaslika NUMBER, in_mesic NUMBER, in_rok NUMBER)
RETURN VARCHAR2
AS
v_vysledek VARCHAR2;
BEGIN
SELECT trpaslici.id, trpaslici.jmeno, id_sachty, sachty.sachta INTO v_vysledek, MAX(tezby.skutecnost)
FROM trpaslik.trpaslici
JOIN trpaslik.tezby ON trpaslici.id = tezby.id_trpaslika
JOIN trpaslik.sachty ON tezby.id_sachty = sachty.id
WHERE trpaslici.id = in_id_trpaslika AND (TO_CHAR(den, 'MM') = in_mesic) AND (TO_CHAR(den, 'YYYY') = in_rok)
GROUP BY trpaslici.id, trpaslici.jmeno, id_sachty, sachty.sachta
HAVING MAX(tezby.skutecnost) =
(SELECT MAX(tezby.skutecnost)
FROM trpaslik.trpaslici
JOIN trpaslik.tezby ON trpaslici.id = tezby.id_trpaslika
JOIN trpaslik.sachty ON tezby.id_sachty = sachty.id
WHERE trpaslici.id = in_id_trpaslika AND (TO_CHAR(den, 'MM') = in_mesic) AND (TO_CHAR(den, 'YYYY') = in_rok)
GROUP BY trpaslici.id, trpaslici.jmeno);
RETURN v_vysledek;
END;

[zabi]

SELECT sachta_max(7,2,2006) FROM DUAL;