Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Modrá je dobrá
zelená je lepší

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Klub Database (mysql,...) [ŽP: neomezená] (kategorie Programování) moderuje melkor_unlimited.
Archiv
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: ywlwgdc
[ 1008 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
pepak pepak - Pepak.net 4.12.2007 12:58  614
Bredy [611]: Mysli si o me, co chces.

Tessien [612]: Moje presne vyjadreni nebylo, ze "NF skodi", ale ze "striktni dodrzovani NF spis skodi"
bredy 4.12.2007 12:14  613
TessienTen termín znám. Ale odsunul bych ho někam do speciálních oblastí, kde se honí výkon než konzistence. Nemyslím si, že by to byl náš příklad.
tessien Tessien Of course slavery is the worst thing - that ever happened. But maybe... 4.12.2007 11:49  612
Bredy [611]: Teď si velice klesl v mém hodnocení, takže na tvé příspěvky se už dívám spíš jako na názory BFU. - proc? Vzdyt ma pravdu :)
Teda, nevim, jestli bych primo pouzil formulaci "skodi", ale rozhodne ne vzdy je vhodne mit NF. Pojem "denormalizace" ti neco rika?
bredy 4.12.2007 10:51  611
pepakpak jejich striktni dodrzovani spis skodi.
Teď si velice klesl v mém hodnocení, takže na tvé příspěvky se už dívám spíš jako na názory BFU.

melkor_unlimited: Nic proti tomu nemám, záleží na zadání. Mě osobně by se spíš líbil transakční model, kdy každá změna má informace: kdy, kdo a proč, jako se používá třeba v SVN. Myslím si, že tenhle model je úplně nejlepší. Pokud někde dochází ke změně, asi by bylo dobré vědět, proč a kdo ji provedl. Ale to už jsme se dostali hodně daleko od původního zadání.
pepak pepak - Pepak.net 4.12.2007 06:39  610
Bredy: Pozadavek znel na MSSQL.

Tvoje predstavy o zabranem miste jsou IMHO prehnane. platnost_od je shodou okolnosti velice uzitecny field - je daleko rychlejsi vytahnout zaznam pomoci (platnost_od<=:datum AND platnost_do>:datum) nez pomoci nejakeho ROWS (resp. v MySQL LIMIT) nebo dokonce subselectu s MAX.

Pro pouziti treti normalni formy neni nejmensi duvod. Normalni formy jsou fajn pro hruby navrh, pro praktickou realizaci (zvlast v databazi s transakcemi, referencni integritou a triggery) pak jejich striktni dodrzovani spis skodi.
melkor_unlimited melkor_unlimited Ltd. 4.12.2007 06:19  609
Bredy [608]: Ono už vůbec třeba přidávat platnost_od je zbytečná informace.
... až na případy, kdy je přímo vyžadována.

Znám pár takových. Obvykle se jedná o dopředné zadávání změn. A do hostorické tabulky se přesouvají až po uplynutí data PLATI_DO.
bredy 3.12.2007 23:42  608
pepak. Je to další položka na víc. Další field, který zabírá místo, a to může být docela dost, Bez znalosti vnitřní implementace mohu říct, že idx zvětší přidaná data o dalších 50%. Ono už vůbec třeba přidávat platnost_od je zbytečná informace.

MySQL má INSERT IGNORE

A aby jsme to měli ve třetí normální formě, správně by se tam mělo uložit ID historického záznamu, který bude obsahovat datum změny, jméno uživatele, který provedl změnu a třeba komentář. Samozřejmě změny provádím v transakci tak aby celá série změn získala jeden záznam v tabulce historie

table (idx,a,b,c)
hist_table (idx,a,b,c,histidx)
history(histidx, kdy, kdo, proc)
pepak pepak - Pepak.net 3.12.2007 19:44  607
Bredy: Je to nutne proto, ze tu "kolizi" musis nejak vyresit. Byla by dost prasarna nechat to byt a proste v aplikaci zahazovat chyby "poruseni jedinecnosti v tabulce XYZ". To bys musel misto INSERTu pouzit nejaky REPLACE, pokud ho tvoje databaze ma, nebo vubec napred SELECTem testovat a pak bud INSERTovat nebo UPDATovat. To uz mi prijde jednodussi proste vzdy insertovat a spolehnout se na to, ze mi to ten autoinc klic rozlisi.

jaký je rozdíl mezi
Rozdil nastane treba v okamziku, kdy dva uzivatele zmeni stejny zaznam ve stejnou chvili. Nebo kdyz jeden zmeni jeden field zaznamu a druhy druhy field.
bredy 3.12.2007 17:09  606
otázka je, zda je to nutné, tedy zda je nutné sledovat sekundovou historii. V běžné situaci asi ne.

jaký je rozdíl mezi
uloz historii,zmen,uloz historii,zmen
a
uloz historii,zmen,zmen

Jedine tak, ze prvni zmena nebude ulozena v historii a bude to vypadat, ze se to zmenilo naraz az ve druhe zmene. IMHO stejne casem je dobre nektere hodne stare zaznamy mazat, pokud te tak daleko nezajima podrobna historie

pepak pepak - Pepak.net 3.12.2007 17:06  605
Bredy: Neni, prave pro ten pripad "okamzite zmeny".
bredy 3.12.2007 17:05  604
pepakklíč autoinc je imho zbytečný
pepak pepak - Pepak.net 3.12.2007 15:33  603
Ta historicka tabulka by IMHO mela obsahovat vsechny sloupecky z normalni tabulky, plus 3 dalsi:
1) klic (autoinc)
2) datum od (timestamp)
3) datum do (timestamp)

Vzhledem k tomu, ze je pozadavek na MSSQL, tak neni problem to v triggeru osetrit vsechno.
bredy 3.12.2007 14:56  602
knedleNo to je právě ten problém. Proto možná řešení s dvěmi tabulky je lepší. V hlavní tabulce mám normálně atomické číslo, v historické tabulce mám normální index - idx z normální tabulky (určitě bude atomické), a pak některé z datumů (například platí_do). To určuje záznam přesně, protože by němělo nastat, že se do historie uloží dva záznamy se stejným datumem plati_do. A pokud ano, je celkem logické, že druhý zápis selže,protože zaznamenávat změny v tak ktátkém čase nemá až tak valný význam.
bredy 3.12.2007 14:52  601
huhOno se může jednat o kombinaci řešeních. Pro rychlý přístup je možná lepší mít vždy aktivní tabulku a pak historickou. Historická tabulka obsahuje záznamy s datumy, tak jak jsem popsal, aktivní tabulka obsahuje normálně záznamy tak jak je běžné.

Ovšem každá změna znamená nejprve přesunout měněné záznamy do historie a pak provést update. Což by ovšem nemuselo být tak těžké. Stačí:

table(idx,a,b,c,d)
hist_table(idx,a,b,c,d,plati_do}

INSERT INTO hist_table SELECT *, NOW() FROM table WHERE cond;
UPDATE table SET .... WHERE cond;

Pro výpis historie pro určité datum by se muselo udělat
SELECT DISTINCTROW idx,a,b,c,d FROM hist_table WHERE plati_do > vybrane_datum ORDER BY plati_do DESC

Tím supluji chybějící plati_od, protože se mi zobrazí vždy nejnovější záznam starší než zadané datum. Nicméně pokud by to byl problém, pak je nutné pravděpodobně vést plati_od v aktivní tabulce, aby se pak mohlo toto datum přepsat do historie jednoduchým SELECTem.

Další varianta jak vyrobit plati_od za předpokladu že jej chci mít v hist_table.

INSERT INTO hist_table SELECT *,MAX(hist_table.plati_do),NOW() FROM table LEFT JOIN hist_table ON table.idx = hist_table.idx WHERE cond

Ale LEFT JOIN nebudí moc důvěru v efektivitě.
knedle knedle online - Krabice živých 3.12.2007 14:51  600
dotaz na bredyho reseni:

primarni klic je pak co? id (bez ai) a casove razitko zacatku?

nebo je tam standardni prim klic autoinc - ale pak by to muselo mit take jeste nejake jine pseudoid - ve stejne tabulce nebo jine?

[ 1008 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt