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

Něco navíc v zeleném?
A proč ne...

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: zwitfvm
[ 1008 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
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?
edmundl 3.12.2007 14:21  598
konkrétní řešení je samozřejmě závioslé na tom, co přesně se od toho požaduje. Dotaz byl zadán velmi obecně a tak je možné použít i více řešení.
huh huh 3.12.2007 14:14  597
Me teda nejnormalnejsi prijde Bredyho reseni
pepak pepak - Pepak.net 3.12.2007 11:13  596
Tak vidis.
bredy 3.12.2007 10:57  595
pepakJá tohle viděl v informačním systému FNKV (Fakultní Nemocnice Královské Vinohrady)
edmundl 3.12.2007 10:57  594
Varianta 1 je sice pracnější na začátku, ale při práci s historickými daty se ti to vrátí, protože s nimi můžeš pracovat skoro stejně jako s živými. To ve variantě 2 bude dohledávání stavu mnohem pracnější.
knedle knedle online - Krabice živých 3.12.2007 10:25  593
jsou jeste nejake vyhody nevyhody:

1/ kopie zive tabulky
- vyhoda: prehlednost
- nevyhoda: pracnost

2/ jedina tabulka historie, kam se ukladaji data ze vsech tabulek
- vyhoda: mensi pracnost
- nevyhoda: neprehlednost, snad i velikost tabulky co do poctu zaznamu (?)

-- u teto je otazka, zda ukladat vsechna pole, nebo jen ty zmenena
- pokud nekompletni, spatne by se asi dohledavali ostatni data stejnho zaznamu
- pokud kompletni, velke narustani dat v teto tab, lze rict, ze i redundance dat


a jeste, pokud se dela takovato historie, dela se to pred novou zmenou (tj. zpetne - aktualni stav neni v tabulce historie) nebo hned po zmene (aktualni stav je i v tabulce historie)
pepak pepak - Pepak.net 3.12.2007 10:22  592
Bredy: To neni dobre reseni. Databaze jsou sice delane, aby se vyporadaly s velkym mnozstvim zaznamu, ale presto je lepsi ty neaktivni necpat do zive databaze. To by se snad hodilo v pripade, ze VZDY potrebuju delat s historii, ale to plati jen u velice malo tabulek.

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

(c) 2001-2011 Lopuch.cz   
Kontakt