Jak začít s programováním DB?

[Logik]

MySQL stačí tak na úplný základy SQL - tam totiž stačí cokoli.
Na triggery atd. už ne, tam už to má natolik "zprasený", že to jen učí blbejm návykům. Autentizaci alá mysql jsem taky nikdy nepřišel na chuťm ale dejme tomu. Check constraints co vím taky nefunguje. Atd.... Jediný plus mysql je vcelku snadná instalace, ale tu má už dneska postgresql nebo firebird taky.

[Reklama]

[jk]

IMHO je potřeba oddělit dvě roviny - teorii a její použití v praxi.

Teorii, zejména co se týká základů relační algebry a konceptů, to se ze žádného konkrétního produktu naučit nelze. Bohužel se to hodně podceňuje, spousta lidí rovnou skočí do nějakého produktu, nikdy si tuto díru ve znalostech neuvědomí a uniká jim část konceptů a principů - což následně vede k všelijakým prasárnám (dámy prominou).

mozna by se mel (nejen) OP nejdriv zamyslet nad tim, proc jste pouzil to spojeni spousta lidí . Proc jste nepouzil malokdo, vyjimecne ...

[anonym]

Ja bych jen chtel rict, ze pojmem DB ci slovu databaze se nemusi jen skryvat relacni databaze...

[Logik]

Jenže s jinýma databázema se IMHO neni moc co učit.... Pokud pominu různé objektové a xml databáze, které se prakticky nepoužívají, tak zbývají jen noSql databáze - a na nich v podstatě není co k učení :-). To je jen o málo chytřejší filesystém - a ještě jsem nikoho neslyšel říkat, naučte mě pracovat se soubory....

[eronlines]

Dobrý den,

Řešim podobnou věc jako autor tématu. Mam nějaký zkušenosti s firebirdem v kombinaci s PHP. Dokumentace je imho dostatek (Kniha od Císaře, na google groups, IBPhoenix...). Takže nějakou tu terminologii znám, o architektuře SŘBD mam taky ponětí. V administračních nástrojích se orientuju. Používat jednodušší SQL dotazy umim. (SELECT, INSERT, UPDATE, JOIN, transakce, atp.)

Chci se naučit nějakou technologii víc do hloubky a následně ji využívat jak pro webové tak pro desktopové aplikace. Primární platforma je Windows, ale Linuxu se nebránim. Tušim že bych se měl učit: modelování a návrh DB, triggery, UDF.

Myslim že je FirebirdSQL super. Jenže má jednu velkou nevýhodu. A to je podpora na hostingách. MySQL se mi zdá jako krok zpět, o PostreSQL toho moc nevim, ale letem světem jsem se dočetl že neni moc výkonný.

Takže který systém je podle vás vhodnější kompromis, FirebirdSQL, nebo PostgreSQL?

[Reklama]

[backup]

.. modelovani, navrh ...

si vzdy vzpomenu na ten fantasticky film 'Bajecni muzi na letajicich strojich' a na tu scenku, kdy velitel predcita pred skupinou vojaku cisaruv rozkaz:

'narizuji, ze zavod Londyn - Pariz musi vyhrat rakousky dustojnik'

A vybrany distojnik se pta, jak se nauci letat.

'no prece z vojenske prirucky' ... zni odpoved.

[Pavel Stěhule]

Dobrý den,

Řešim podobnou věc jako autor tématu. Mam nějaký zkušenosti s firebirdem v kombinaci s PHP. Dokumentace je imho dostatek (Kniha od Císaře, na google groups, IBPhoenix...). Takže nějakou tu terminologii znám, o architektuře SŘBD mam taky ponětí. V administračních nástrojích se orientuju. Používat jednodušší SQL dotazy umim. (SELECT, INSERT, UPDATE, JOIN, transakce, atp.)

Chci se naučit nějakou technologii víc do hloubky a následně ji využívat jak pro webové tak pro desktopové aplikace. Primární platforma je Windows, ale Linuxu se nebránim. Tušim že bych se měl učit: modelování a návrh DB, triggery, UDF.

Myslim že je FirebirdSQL super. Jenže má jednu velkou nevýhodu. A to je podpora na hostingách. MySQL se mi zdá jako krok zpět, o PostreSQL toho moc nevim, ale letem světem jsem se dočetl že neni moc výkonný.

Takže který systém je podle vás vhodnější kompromis, FirebirdSQL, nebo PostgreSQL?

Když jsem naposledy testoval Firebird a PostgreSQL tak mezi nimi byly minimální rozdíly - a není se co divit. Hrdlo je čtení a zápis na disk, které se projeví u jednodušších dotazů. U složitějších dotazů má PostgreSQL navrch. Co se týče rychlosti, tak hodně záleží na interface, které používáte. BDE komponenty jsou vyladěné pro Interbase, tudíž i Firebird a volně dostupné komponenty pro PostgreSQL jsou horší. Musí se použít nativní komponenty, které obchází BDE.

K Vaší otázce. musíte napsat pro co je ta či ona db vhodnější kompromis. Obě db se od sebe docela dost liší, a v něčem jsou si zase docela podobné. Firebird je docela dobrá db pro jednoduchá, podvojná účetnictví pro malé firmy. Nemusí se instalovat a běží s minimální režií. PostgreSQL se používá spíš na větší projekty - nabízí větší komfort a lepší výkon při velké zátěži. Kromě jiného PostgreSQL podstatně lépe pokrývá ANSI SQL 200x, nabízí větší komfort pro psaní uložených procedur, obejde se bez obslužných knihoven. Na druhou stranu nepodporuje COLLATEs a také třeba uložené procedury někdo nepoužívá. Takže vždy záleží na použití. Každá z těch db má dost odlišnou cílovou skupinu, která dost odlišně používá db.

[eronlines]

Když vezmu v úvahu pouze technologie které znám teď, tak můžu využívat buďto firebirda přez nativní knihovnu v PHP (gds32.dll, nebo novější fbclient.dll), anebo z C# přez nativní Firebird ADO.NET Data Provider v.2.5.0.

Pro následující srovnání berme v úvahu firebird architekturu super server...
"lepší výkon při velké zátěži" takže dokáže obsloužit na stejném HW více požadavků ve stejném čase?

Množství diskových I/O operací má co nejvíc omezit cache (třeba pro často opakované jednoduché selecty). Je nějaký zásadní rozdíl v implementaci cache?

Firebird je poměrně nenáročný na RAM. Jak je na tom postgre?

Co máte přesně na mysli tou režií? Data "navíc" která se přenášejí mezi klientem a serverem? Postgre má podle vás režii větší?

No vypadá to že si o Postgre budu muset sehnat nějakou literaturu...

[Pavel Stěhule]

No primárně PostgreSQL lépe pracuje se shared memory v SMP architektuře. Aktuálně Firebird v Super Server čeká na zámcích. Což by ovšem mělo být odstraněno v 2.5 Firebirdu, možná v budoucí 3.0. K tomu má pg několik triků - např. synchronizaci SQL dotazů. Takže na jedním čtením z disku, cache lze obsloužit více uživatelů.

Ohledně paměti - tam si asi vezme PostgreSQL víc, ale je potřeba oddělit paměť pro vlastní běh - zásobník, halda a pak paměť pro datové operace - work_mem a shared_buffers. Ta první paměť se pohybuje do stovek kb, work_mem a shared_buffers přesně jak nakonfigurujete - tudíž spíš v MB nebo GB. A tak nemá moc cenu řešit velikost zásobníku, neb work_mem a shared_buffers jsou řádově větší - tam jde o to, aby neprobíhal external sort. Případně aby se data držela co nejdéle v cache. Hodně záleží s jakými daty se pracuje. Mohu Pg nakonfigurovat a rozjet na stroji s 16MB paměti zrovna tak s 128GB. Ale takové minimum jako má Firebird pg nemá. Rozhodně se nepoužívá v mobilech nebo do tanku .

[Tomáš Vondra]

IMHO je potřeba oddělit dvě roviny - teorii a její použití v praxi.

Teorii, zejména co se týká základů relační algebry a konceptů, to se ze žádného konkrétního produktu naučit nelze. Bohužel se to hodně podceňuje, spousta lidí rovnou skočí do nějakého produktu, nikdy si tuto díru ve znalostech neuvědomí a uniká jim část konceptů a principů - což následně vede k všelijakým prasárnám (dámy prominou).

mozna by se mel (nejen) OP nejdriv zamyslet nad tim, proc jste pouzil to spojeni spousta lidí . Proc jste nepouzil malokdo, vyjimecne ...

Nejsem si jist jak mám váš komentář interpretovat, jestli jako souhlas nebo nesouhlas s tím mým

Každopádně můj názor je že je fajn si nejdříve ošahat základy technologie - a je úplně jedno jestli to je MySQL, SQLite nebo DB2, protože různé advanced vlastnosti v dané fázi dotyčný neocení, a pak se pustit do té teorie. IMHO je pak jednodušší za tou teorií vidět konkrétní význam. No a pak zase k nějakému tomu produktu a učit se složitější věci. Pochopitelně to není striktně oddělené, ty "fáze" se prolínají. Ale je to můj osobní názor, někomu zase může vyhovovat nejdřív našprtat teorii a až pak se pustit do praktických pokusů ...

Každopádně těch lidí kteří nejsou "postižení" znalostí teorie je skutečně hodně, často to vede například k tomu že za standard pokládají chování konkrétního produktu, bez ohledu na jeho nesmyslnost, atd. O tom že terminologii používají velmi volně raději ani nemluvě. A když takový člověk napíše knížku, je to vesměs velmi smutné čtení - před časem se mi například dostala do ruky kniha ve které autor zcela vážně tvrdil že označení "relační" znamená že databáze dokáže zachytit vztahy (anglicky "relations") mezi tabulkami. Takovou knihu doporučuji zabalit do igelitu aby nekontaminovala okolí a velkým obloukem zahodit.

[Tomáš Vondra]

Chci se naučit nějakou technologii víc do hloubky a následně ji využívat jak pro webové tak pro desktopové aplikace. Primární platforma je Windows, ale Linuxu se nebránim. Tušim že bych se měl učit: modelování a návrh DB, triggery, UDF.

Budu se opakovat, ale zkuste si sehnat ta skripta od Halašky. Základy modelování (Entity-Relationship Diagramy apod.), normální formy, normalizace, denormalizace - to všechno je tam poměrně pěkně vysvětleno. Autor tomu rozumí a navíc je to česky, což je na začátku velká výhoda.

Myslim že je FirebirdSQL super. Jenže má jednu velkou nevýhodu. A to je podpora na hostingách. MySQL se mi zdá jako krok zpět, o PostreSQL toho moc nevim, ale letem světem jsem se dočetl že neni moc výkonný.

To s tím výkonem (že je PostgreSQL pomalý) je takový vousatý stereotyp. Kdysi dávno se říkalo že MySQL je rychlá ale nespolehlivá, PostgreSQL je spolehlivý ale pomalý. MySQL si netroufám komentovat, nepožívám ji intenzivně, nicméně u PostgreSQL se situace radikálně změnila. Dovolím si ocitovat tabulku uvedenou v nové knížce od Grega Smithe, kde srovnává verze od 8.0 do 8.4:

veze	peak (read-only) TPS	number of clients (at peak)
8.0.21	1256	4
8.1.17	5620	14
8.2.13	8109	18
8.3.7	13984	22
8.4.1	13569	22

z čehož je vidět že tam je řádový nárust výkonu. Ale uznávám že to je syntetický benchmark, v praktickém nasazení se to může lišit (a to na obě strany!).

Co se týká sdílených hostingů s PostgreSQL, v ČR je situace žalostná - vesměs jsou to hodně staré verze (např. 8.1), zhusta zcela nevytuněné. Takže jedinou možností je buď vlastní server (byť VPS), nebo zahraničí (ale pak to zase nebude v NIXu).

Takže který systém je podle vás vhodnější kompromis, FirebirdSQL, nebo PostgreSQL?

Bohužel neznám Firebirda dostatečně dobře abych na to dokázal odpovědět. Ale pokládám to za zajímavou alternativu o které bych se rád dozvěděl víc - i z tohoto důvodu jsme se s Jiřím Císařem domluvili že na letošním P2D2 bude mít o Firebirdu přednášku.

[jk]

IMHO je potřeba oddělit dvě roviny - teorii a její použití v praxi.

Teorii, zejména co se týká základů relační algebry a konceptů, to se ze žádného konkrétního produktu naučit nelze. Bohužel se to hodně podceňuje, spousta lidí rovnou skočí do nějakého produktu, nikdy si tuto díru ve znalostech neuvědomí a uniká jim část konceptů a principů - což následně vede k všelijakým prasárnám (dámy prominou).

mozna by se mel (nejen) OP nejdriv zamyslet nad tim, proc jste pouzil to spojeni spousta lidí . Proc jste nepouzil malokdo, vyjimecne ...

Nejsem si jist jak mám váš komentář interpretovat, jestli jako souhlas nebo nesouhlas s tím mým

je to nesouhlas. Modelovani a navrh se nelze naucit, zrovna tak jako se neni mozne naucit zpivat jak Gott a nebo kreslit jako Picasso. Je to vyhrazeno jen male skupine populace a takovi lide by se urcite neptali, jak se naucit programovat DB, to uz davno nejak intuitivne vedi.

'Zprasene' navrhy nejsou podle me tedy vysledkem nezajmu o teorii, ale pouze vestavena vlastnost relacnich systemu. K tomu, aby optimalne ty systemy fungovaly je nutne, aby znacna cast pracovniku mela ty 'nadlidske' schopnosti. Protoze to v lidske spolecnosti nelze dosahnout, musite pak k tem 'nefunkcim' aplikacim prijit Vy, pan Stehule nebo par dalsich, kteri se s tim vyznaji a musite to opravit. To by vlastne pro ty schopne nebylo tak spatne, ale i pro ne ma den jen 24 hodin.

[Tomáš Vondra]

je to nesouhlas. Modelovani a navrh se nelze naucit, zrovna tak jako se neni mozne naucit zpivat jak Gott a nebo kreslit jako Picasso. Je to vyhrazeno jen male skupine populace a takovi lide by se urcite neptali, jak se naucit programovat DB, to uz davno nejak intuitivne vedi.

'Zprasene' navrhy nejsou podle me tedy vysledkem nezajmu o teorii, ale pouze vestavena vlastnost relacnich systemu. K tomu, aby optimalne ty systemy fungovaly je nutne, aby znacna cast pracovniku mela ty 'nadlidske' schopnosti. Protoze to v lidske spolecnosti nelze dosahnout, musite pak k tem 'nefunkcim' aplikacim prijit Vy, pan Stehule nebo par dalsich, kteri se s tim vyznaji a musite to opravit. To by vlastne pro ty schopne nebylo tak spatne, ale i pro ne ma den jen 24 hodin.

S tím že by se modelování a návrh nešlo naučit nesouhlasím - netvrdím že každý je "natural born designer" ale na druhou stranu to není žádná raketová věda. Z větší části jsou to relativně jednoduchá pravidla která rychle "přechází do krve" ale samozřejmě je i pár oblastí kde je to tak asi není. Osobně si myslím že je to spíš o impulsech a vnitřní motivaci, nikoliv o tom že by to vývojáři nebyli schopni intelektuálně zvládnout.

Vemte si třeba normální formy - to je věc o které by měl mít ponětí každý DB vývojář. Ne, netvrdím že je nutné umět z hlavy přesnou definici jednotlivých normálních forem, ale vědět k čemu jejich porušení vede apod. Spousta vývojářů bohužel bere např. aktualizační anomálie jako nutné zlo, nenapadne je že vhodnou dekompozicí se jim lze vyhnout apod.

A nemohu mluvit za Pavla, ale pro mne opravování "zaprasených" návrhů představuje jednu z nejhorších forem mučení ...

[Pavel Stěhule]

IMHO je potřeba oddělit dvě roviny - teorii a její použití v praxi.

Teorii, zejména co se týká základů relační algebry a konceptů, to se ze žádného konkrétního produktu naučit nelze. Bohužel se to hodně podceňuje, spousta lidí rovnou skočí do nějakého produktu, nikdy si tuto díru ve znalostech neuvědomí a uniká jim část konceptů a principů - což následně vede k všelijakým prasárnám (dámy prominou).

mozna by se mel (nejen) OP nejdriv zamyslet nad tim, proc jste pouzil to spojeni spousta lidí . Proc jste nepouzil malokdo, vyjimecne ...

Nejsem si jist jak mám váš komentář interpretovat, jestli jako souhlas nebo nesouhlas s tím mým

je to nesouhlas. Modelovani a navrh se nelze naucit, zrovna tak jako se neni mozne naucit zpivat jak Gott a nebo kreslit jako Picasso. Je to vyhrazeno jen male skupine populace a takovi lide by se urcite neptali, jak se naucit programovat DB, to uz davno nejak intuitivne vedi.

'Zprasene' navrhy nejsou podle me tedy vysledkem nezajmu o teorii, ale pouze vestavena vlastnost relacnich systemu. K tomu, aby optimalne ty systemy fungovaly je nutne, aby znacna cast pracovniku mela ty 'nadlidske' schopnosti. Protoze to v lidske spolecnosti nelze dosahnout, musite pak k tem 'nefunkcim' aplikacim prijit Vy, pan Stehule nebo par dalsich, kteri se s tim vyznaji a musite to opravit. To by vlastne pro ty schopne nebylo tak spatne, ale i pro ne ma den jen 24 hodin.

Zprasené návrhy jsou výsledkem nezkušenosti, neznalosti a "poddajnosti". Ono se to poddá, nebrání a ve většině případů na to nikdo nepřijde. Navíc, v reálném životě, když se něco nepovede, tak se to za nějaký čas předělá nebo po opotřebení zahodí. Což u sw neplatí. Akorát mizerně navržený sw otravuje život programátorům a někdy i uživatelům. Ale "prasení" není jen záležitost relačních db, prasí se domy, zákony, silnice, ... Technologie jsou v tom nevinně. Programování je řemeslo. Člověk se musí spálit, musí mít dobré učitele, musí chtít se učit, a musí mít příležitost se učit a musí chtít dělat věci dobře. No a pak můžete dělat dobrý věci. Je důležité, aby člověk věděl jak to funguje, aspoň zhruba, aby nějaká část pro něj nebyla černá skříňkaA pokud máte k tomu talent, tak můžete dělat lepší než dobré věci. Myslím si, že analytikem se člověk musí narodit - jeden z mých profesorů říkával, že člověk musí umět myslet za roh, vidět souvislosti, umět poznat, co je důležité a co není, umět to vykomunikovat, protože každý si myslí, to co dělá on je důležité, ... nicméně relační db se dají naučit - minimálně na úroveň "dobře", když je vůle.