Návrh databáze (diskuse)

[VícNežNic]

Hm, proč a pro koho takové články?

[Käyttäjä 11133]

Jaký smysl má ta patička, něco mi snad uniklo?

[VícNežNic]

No, tobě by to uniknout nemělo. Ale asi se David nepochlubil

(jinak každou zmínkou riskuju život, tak si toho važte)

[David Watzke]

Riskuješ :-P, ale to sem nepatří...

[Käyttäjä 11133]

Aha, už vím :)

[Kníže Ignor]

VícNežNic totiž umí řešit jenom dobře zadané úlohy. A ještě se tím chlubí!

[VícNežNic]

Já umím řešit všechno. Jenom se nesmí klást přehnaný důraz na správnost výsledku.

[Käyttäjä 11133]

Jasně, prázdná množina řešení je taky řešení.

[VícNežNic]

Ona nemusí být ta množina řešení vždy prázdná. Prázdný může být třeba průnik množiny mých řešení a správných řešení. Ale to jsou maličkosti, to se stává.

[Käyttäjä 11133]

Tak to je to s ním špatné.

[Luk]

No, pravda je, že ti co by to potřebovali, si to stejně nepřečtou

[Dalibor Smolík]

Opakování je matka moudrosti. Šel jsem do sebe a upravil si nedostatek v procesu rušení faktur.(jo, ty kaskády ... )

[Pavel 'lingeek' Szalbot]

Nahradil bych článek linkem - základy databází. A vytahal spoustu lidí za uši...

[Luk]

Musel jsem to napsat, protože jsem si nedávno přečetl tohle (část druhá - "Kalvárie údržby kódu") a opravdu mi to nedalo

[Lukáš Zapletal]

NJN s0 blog rules Pškný příspěvek, opakování matka moudrosti.

[springer]

...Pak stačí, aby si nějaký bláznivý manažer vymyslel, že přečísluje oddělení, a je o zábavu postaráno ...

to jsou ty typicke priklady, ktere se vykladaji studentum ve skolach a na ruznych kurzech. Nemaji s praxi vubec nic spolecneho. Bohuzel jsou ucitele na skolach (i tech vysokych) vetsinou lide, kteri jeste nikdy nemuseli nejaky projekt obhajovat v praxi.

Ono to je totiz tak, ze kdyz si nekdo rozmysli neco precislovat, co je zafixovano na stovkach formularu, telefonich seznamech, prospektech a pod. tak ta prace se zmenou techto dat je 100 x vetsi, nez ten jeden batch, ktery v noci ty udaje v databazi zprehazi.

Pamatuj: cislo dodavatele jako primarni klic neni chybou!

[Luk]

...Pak stačí, aby si nějaký bláznivý manažer vymyslel, že přečísluje oddělení, a je o zábavu postaráno ...

to jsou ty typicke priklady, ktere se vykladaji studentum ve skolach a na ruznych kurzech. Nemaji s praxi vubec nic spolecneho.

Tenhle příklad jsem uvedl právě proto, že jsem ho v praxi skutečně zažil (naštěstí ne s databází, která by byla takto špatně navržena).

Ono to je totiz tak, ze kdyz si nekdo rozmysli neco precislovat, co je zafixovano na stovkach formularu, telefonich seznamech, prospektech a pod. tak ta prace se zmenou techto dat je 100 x vetsi, nez ten jeden batch, ktery v noci ty udaje v databazi zprehazi.

Zrovna to číslo oddělení je v podstatě interní záležitost, která nemusí nikde příliš figurovat (např. pouze na vnitrofiremních účetních dokladech).

Pamatuj: cislo dodavatele jako primarni klic neni chybou!

Nemusí být, ale obecně je lepší vyhnout se použití atributu, který přímo nese nějakou eventuálně měnitelnou informaci.

[happy barney]

Pamatuj: cislo dodavatele jako primarni klic neni chybou!

Nemusí být, ale obecně je lepší vyhnout se použití atributu, který přímo nese nějakou eventuálně měnitelnou informaci.

suhlas, kazda tabulka by podla mna mala mat int4/int8 stlpec id, idealne auto-increment idealne unikatny v celej db

ad cislo dodavatela, niekto ich ma integer (123), iny si napr k cislu priklada info o roku (123/2004), dalsi stat (SK-123), atd, atd. Jeden dodavatel moze mat v roznych casovych obdobiach rozne cisla. To, ze si autor sw nevie predstavit inu situaciu, to nie je chyba nasadenia

[Kyosuke]

„idealne unikatny v celej db“

Proč mi to smrdí objekty?

[happy barney]

nemusi smrdiet ... je to len obrana voci odpozorovanym castym chybam, ked niekto nevie pisat joiny. Taka primitivna kontrola datoveho typu aj v selectoch.

[zde]

Jde o velmi častou praxi ve větších systémech.. umělé klíče různých tabulek běží od různých počátečních hodnot, s "dostatečnými" rozestupy, takže stačí vidět první cifru a hned je jasné do které tabulky to ukazuje.. a ano, smrdí to objekty, a je to dobře :)

[Ladislav Thon]

Přirozené spojení, to taky nějaká databáze umí? V MySQL je klauzule using, která to řeší IMHO hezkým jednoduchým způsobem, ale o implementaci opravdového přirozeného spojení jsem ještě neslyšel.

[Luk]

Co třeba:

CREATE TABLE T1 (t1_id INT, t1_txt VARCHAR(100),
PRIMARY KEY (t1_id));

CREATE TABLE T2 (t2_id INT, t2_txt VARCHAR(100), t1_id INT,
PRIMARY KEY (t2_id));

...

SELECT t1_txt,t2_txt FROM T1 NATURAL JOIN T2;

[Ladislav Thon]

No jo, ono to tam fakt je, už mlčím (ale používat mne to nikdo nedonutí :) ).

[Pavel Kysilka]

mazaci dodaji:

- pouzivat pohledy a obcas hromadne ozkouset, zda jeste funguji...

- nedelat pravopisne chyby v nazvech tabulek a sloupcu. pak by clovek pri implementaci a s omezenymi pravy a s rozkopirovanim v kodu zabijel....

- selecty a klidne i dalsi provadet podle potreby do xml nebo do neceho strukturovaneho.

- mrknout se na to, ze existuji i objektove database nebo objektova struktura na relacni databasi

- pouzivat database, kde neni problem dostat zpet data z dumpu

- pouzivat database s prijatelnym vyvojovym prostredim

- database neni vhodna na ukladani videa a __ne vzdycky__ na ukladani souboru.

- vytvaret tabulky stylem forum0, forum1, forum2 a doplnte neni to prave

- pres sql se daji vyborne generovat skripty

- mazak kvuli zjisteni casu neprejde z databasove konsole jinam nebo se nediva na hodinky, ale napise select now() ci jiny prikaz na zjisteni casu.

- pouzivat ty transkace....

- mysql neni zrovna vhodna na vetsi ucetnictvi..... flamesisti si to pokusi nejdrive napsat.

- je dobre si zkontrolovat, ze do database jde to prave kodovani. sice se s tim pocita automaticky, ale webmasteri jaksi ne...

- podivat se treba na to, jak ty database pracuji a na princip jejich fungovani.

- selectuj jen co potrebujes. ta hvezdicka sice setri praci, ale brutalne obcas zpomaluje. dokonce jsou database, ktere neumi poradne limit a offset - ta s tou divnou baterkou na rootu.

- je dobre podtaktovat cpu pri zkouseni sveho vytvoru.

a je toho mraky co se clovek naucil nebo ho to kolega lstiburek dost dobre naucil.

bye gf

[Luk]

- mysql neni zrovna vhodna na vetsi ucetnictvi..... flamesisti si to pokusi nejdrive napsat

...není vhodná na větší cokoliv (i když verze 5 už je o něco lepší). Čtyřka neumí pohledy a triggery, složitější dotazy jsou pomalé (i v pětce) a má některé další neduhy.

- je dobre si zkontrolovat, ze do database jde to prave kodovani. sice se s tim pocita automaticky, ale webmasteri jaksi ne...

Ať žije čaj

Od doby, co univerzálně používám UTF-8, už mě takové přízemní problémy netrápí

[wake]

CREATE FUNCTION tuid() RETURNS TRIGGER AS $$
DECLARE
 i RECORD;
 q text;
BEGIN
 q:='';
 FOR i IN SELECT id, condition FROM t LOOP
  if( q='' ) THEN
   q:='SELECT * FROM vtx'||i.id||' ';
  ELSE
   q:='UNION SELECT * FROM vtx'||i.id||' ';
  END IF;
  EXECUTE
   'CREATE OR REPLACE VIEW vtx'||i.id|| AS '||
   'SELECT '||i.id||' AS id_t, x.id AS id_x '||
   'FROM x WHERE '||i.condition||' ';
 END LOOP;
 EXECUTE 'CREATE OR REPLACE VIEW vtx AS '||q;
 IF (TG_OP = 'DELETE') THEN
  return old;
 ELSE
  return new;
 END IF;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER tuid AFTER INSERT OR UPDATE OR DELETE ON v
 FOR EACH STATEMENT EXECUTE PROCEDURE tuid();

[Lukáš Zapletal]

existuji databaze (pravda, ne relacni), ktere jsou vhodne (doslova urceny) na ukladani multimedii.

[happy barney]

zakladnou chybou pri navrhu databaz je nepouzivanie nastrojov, ktore to urobia z modelu (povedzme z moderneho UML), rovno aj s pristupovymi kniznicami pre pouzivany jazyk. Niekolko XSLT sablon a problem nenastane

[Luk]

Tyto nástroje jsou velice cenné, ale nejsou samospasitelné. Vždycky to musí člověk zkontrolovat a případně upravit.

[happy barney]

ano, ale na to staci jeden (dvaja) ludia, a odbura sa tym mnozstvo chyb celeho tymu Dalsou vyhodou je to, ze tie nastroje sa nestaraju o prog. jazyk ci db ... sablonu clovek napise raz a pouziva vo vsetkych dalsich projektoch. Tej prace co to usetri ... a btw, (x)emacs je lepsi

[zde]

Jsem jedinej komu přijdou normální formy jako akademickej bulšit odtrženej od reality? Si pamatuju jak nás třeba učili strkat duplicitní atributy do další tabulky, a vůbec jim nevadilo že umělý klíč této tabulky není o mnoho kratší než sám atribut, takže výsledek je nejen složitější, ale i paměťově náročnější.

[Jiří Veselský]

Šedivá je teorie, věčně zelený je strom života...

Máte pravdu, normální formy jsou akademická sračka a najdete spoustu praktických situací, kdy je lepší tyto akademické šablony porušit. NICMÉNĚ, považuju za docela nezbytné je znát a uvažovat v jejich intencích - a podle potřeby je promyšleně porušit kvůli efektivitě.

Problém je bohužel v tom, že hromada lidí tudle teorii vůbec nezná a porušuje ji nikoliv se zacílením na výkon, alébrž v důsledku nedostatečného pochopení celé problematiky. A pak vznikají zoufale neoptimalizované produkční systémy.

Ony totiž i ty akademické sračky mají něco do sebe... Pokud opravdu VÍTE co děláte, tak teoreticky optimální návrh změníte. Tragédie (a bohužel mnohočetná) je v tom, že spousta praktiků ani netuší, jak by ten teoreticky optimální návrh mohl vypadat... A pak vznikají děsné zrůdnosti...

[Luk]

To je přesné

[Michal Kubeček]

To je přesně ono. Ke skoro každému pravidlu existují situace, kdy je žádoucí ho porušit. Ale ten, kdo ho poruší by měl to pravidlo dobře znát, vědět, čím je motivováno a být schopen poznat, kdy nastane ona mimořádná situace. Pokud někdo pravidla porušuje proto, že je nezná, nebo proto, že ze zásady nechce dodržovat "nějakej akademickej bulšit", výsledkem je obvykle katastrofa…

[zde]

..a podle potřeby je promyšleně porušit kvůli efektivitě.

což mi připomíná ,,don't forget that Linux became only possible because 20 years of academic OS research was carefully studied, analyzed, discussed and finally thrown away''

[Jiří Veselský]

Tak toto jsem neznal

[zde]

Jde o 7 let starý a drobet nepřesný citát Ingo Molnara..

http://www.cs.helsinki.fi/linux/linux-kernel/Year-1999/1999-22/1302.html

[Karel Benák]

No nevim jestli jsou normalni formy bullshit, ale co jsem cetl nekolik skript z FELu apod. instituci o tvorbe databazi, pak tam byla vylozene zminka o tzv. procesu denormalizace a ze nekdy je fackt vyhoda pouzit nizsi normalni formu.

Co se tyce mazani v databazi, pravidla ON DELETE CASCADE ON UPDATE CASCADE jsou skvela, ale nekdy se vazne hodi mit implicitni ON DELETE RESTRICT a promazavat to rucne nekolika na sebe navazujicimi prikazy.