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

Tolik rozruchu
jen v Lopuchu

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: jpstsdr
[ 1008 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
straka82 Straka82 8.1.2008 22:31  618
ZdravimNevite o nejakem prehledu, kde je popsano, na jak velky objem dat pouzit jakou db?

Budu delat program, ktery sice nebude mit nijak slozite db schema, ale bude se do nej vkladat relativne velke mnozstvi dat (teda aspon pro me :-) ). Asi tak 20 tisic zaznamu (radku do jedne maloatributove tabulky) za mesic. Mam strach, ze PostgreSQL, ktery normalne pouzivam, nebude stacit. Hlavnim ucelem proste bude to vkladani a jednou za nejakou dobu (ne moc casto), se nad tema datama udela nejaky dotaz.

Mozna mam ale zbytecne obavy a tech 20tisic zaznamu za mesic je tezka pohoda i pro mysql treba :)

Nevite teda nekdo o necem?
melkor_unlimited melkor_unlimited Ltd. 2.1.2008 06:09  617
VítejteVítejte do starého dobrého klubu v novém roce s novým moderátorem a starými dobrými způsoby.
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 2.1.2008 00:28  616
(Moderatorem byl jmenovan melkor_unlimited.)
tessien Tessien Of course slavery is the worst thing - that ever happened. But maybe... 4.12.2007 13:38  615
pepak [614]: dopln tam jeste "v nekterych pripadech" a budu s tebou souhlasit :)
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ý
[ 1008 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt