Autor Zpráva
matak
Profil
umí s něčím takovým pracovat mysql? jak nejlépe zjistit zda záznam byl změněn? timestamp nastavený na on update je nespolehlivý! raději bych něco jiného?? díky
TomášK
Profil
Tu by šlo něco vybrat:
http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html

Jaké máš problémy s timestamp? Zdá se mi, že na toto by měl fungovat...
matak
Profil
musel bych sledovat timestamp i u mssql což je prakticky pro mne nemožné, a také jde o to, že často dochází k updatu řádku a tím se změní datum úpravy, přesto, že záznam se nijak nezměnil stačí dotaz typu

INSERT ... ON DUPLICATE UPDATE

jinak ten odkaz ... kryptovací funkce ... dobrá, ale pokud to nepoužívá mysql nativně tak jak mi to pomůže k porovnání změn? představte si situaci kdy synchronizuji mssql databázi a mysql databázi, nemůžu přece projít např. 100 000 řádků a najednou u nich počítat md5 např. ani vytvořit proceduru, která při updatu vezme jeden sloupeček po druhém a spočítá md5 a uloží do sloupce, to tu databázi snad musí úplně zasekat
Aesir
Profil
matak:
Jde vám o synchronizaci mssql s mysql? Pokud ano, tak se používá fičura Linking Servers
matak
Profil
Ano, ale jde mi o to synchronizovat rozdilne datove struktury, prostě dva systémy
Aesir
Profil
matak:
Tak to už pak není moc o synchronizaci, ale o přenosu dat. :) V případě odlišných struktur je vám přece na nic i checksum nebo jiné hashování záznamů. Jak moc online to potřebujete?
Jestli by nebylo lepší to udělat aplikačně - ve zdrojové databázi udělat přenosovou tabulku, do které budete dávat nové věci k přenosu např. triggerem, následně to přečtete skriptem z nějakého scheduleru, zpracujete dle libosti a smažete z přenosové tabulky, nebo něco podobného.
matak
Profil
interval 5 minut, nevím jestli je to o přenosu dat, podle mne jde o synchronizaci jelikož se data mohou měnit na obou stranách a na jedné straně nemám možnost jakéhokoli zásahu, tedy tam něco jako zásobník změn neprovedu

checksumy slouží k tomu, aby jednou za tu synchronizaci za těch 5 min nebyl generován balík např. 100 000 řádků, ale jen např. těch 100 000 checksumu, které se porovnají a protistrana si pak vyžádá jen ty změny, jestli rozumíte

samozřejmě checksum má být jen jako spolehlivá metoda, ve chvíli, kdy použiji na 100 000 záznamů něco jako INSERT ... ON DUPLICATE UPDATE tak se mi změní timestamp i přesto, že 90% řádků se nijak nezměnilo, proto vidím timestamp jako nespolehlivý
Aesir
Profil
matak:
Tak po menší odmlce mě už napadá jedině binární log (na straně mysql), pokud to nechcete řešit například přes triggery.
matak
Profil
můžeš to prosím trochu rozvést? díky
Aesir
Profil
matak:
Teď nevím kteou z možnosí máte na mysli.
Binární log používá mysql pro replikaci, jsou v něm zaznamenané uložené operace, ale pracovat s tím je docela...no...nic moc prostě :)

Trigger si myslím byl pro vás dobrá volba, dá se navázat na zápisové operace, takže si ty změněné záznamy můžete někam odkládat bokem a pak jednou za čas přenést.

Ona myslq checksum má, ale jen na úrovni celých tabulek, takže dokážete zjistit, zda se změnil počet záznamů v tabulce nebo jestli se změnily data celkově (zjistíte přes show table status), ale tuším, že nad innodb je to nepoužitelné.
matak
Profil
tak nevím jestli někdo používá myisam, ale to je sebevražda ne? pokud taková tabulka neslouží k nějakému logování

Trigger fajn jen se trochu bojím, že to bude mít podstatný dopad na výkon??? názor?

Pravda trigger používám pro zapsání timestampu pri změně řádku, ale ukládat do jiné databáze? navíc stejný problém

při operaci INSERT ... ON DUPLICATE UPDATE vyvolám trigger u všech řádků ne? přesto že 90% se jich nezmění

což je ten důvod proč je pro mne timestamp získaný triggerem nepoužitelný a proč hledám ty checksumy
Aesir
Profil
matak:
tak nevím jestli někdo používá myisam, ale to je sebevražda ne?
innodb neumí fulltext

Trigger fajn jen se trochu bojím, že to bude mít podstatný dopad na výkon??? názor?
nebál bych se toho, pokud není už teď db server přetěžován a nehrajete o každý takt

při operaci INSERT ... ON DUPLICATE UPDATE vyvolám trigger u všech řádků ne?
manuál říká toto:

A potentially confusing example of this is the INSERT INTO ... ON DUPLICATE KEY UPDATE ... syntax: a BEFORE INSERT trigger will activate for every row, followed by either an AFTER INSERT trigger or both the BEFORE UPDATE and AFTER UPDATE triggers, depending on whether there was a duplicate key for the row.
matak
Profil
innodb a fulltext ano vím, ale nedokážu si představit správu databáze bez referenčních klíčů, fulltext jsem zatím vždy oželel

přetěžování serveru no to je taky otázka, prostě se tím zdvojnásobí zátěž na každý zápis což není zrovna moc žádoucí

INSERT DUPLICATE UPDATE jestli mne angličtina neklame, měl jsem pravdu?
Kajman_
Profil *
A můžete si v tom before update triggeru zkontrolovat, zda všechny new hodnoty jsou stejné jako old hodnoty a dle toho si nastavit nebo nenastavit timestamp se změnou?
matak
Profil
to by určitě šlo a napadlo mne to, jen se bojím jak se to celé díky tomu zpomalí?? co když pomocí INSERT ON DUPLICATE UPDATE měním např. v selectu 100 000 řádků? to by asi bylo podstatné zpomalení?
Kajman_
Profil *
Vyzkoušejte, uvidíte.
matak
Profil
no tady si tak trochu rikam ze je to mozna podobne narocne jako vytvaret si vlastni checksum, tedy pri kazdem updatu vzit vsechny sloupce a ulozit jejich md5

hlavně nejsem zas až tak zběhlý v triggerech, ale lze nějak procházet všechny NEW hodnoty? tedy nepřistupovat k vkládaným hodnotám jednotlivé? NEW.id, NEW.name apod. tedy prostě nějakým foreach NEW as ident=>value

?

tabulka s 30 sloupci se bude v triggeru špatně udržovat, když se nějaký sloupec změní, zmizí, přibyde atd.
matak
Profil
jeste si tak rikam kdyz interval synchronizace omezim na cca 20minut, tak by nemusel byt asi az takovy problem vytvorit checksumy tech 100000 radku cca, proste by se vytvareli jednou za cas

je to zhruba pro mysql 100000x spojit hodnoty sloupcu v kazdem radku a vygenerovat md5 to následně uložit do jiné tabulky, to by myslím nebyl takový problém

ovsem stejne je zde problem ze by bylo nutne rozpoznat master a slave coz by slo opet automaticky rozpoznat jedine na zaklade novejsiho timestamp. takze jsem zase skoro na zacatku
Aesir
Profil
matak:

innodb a fulltext ano vím, ale nedokážu si představit správu databáze bez referenčních klíčů, fulltext jsem zatím vždy oželel
až budete potřebovat rychle čísti opravu velké mraky záznamů bez potřeby složitých záznamů, budete za rychlý myisam engine hodně vděčný :)

přetěžování serveru no to je taky otázka, prostě se tím zdvojnásobí zátěž na každý zápis což není zrovna moc žádoucí

triggery mají minimání vnitřní režii, takže to bude pouze o těch dotazech, které se budou vykonávat a tam už je ta zátěž docela měřitelná

INSERT DUPLICATE UPDATE jestli mne angličtina neklame, měl jsem pravdu?
ten kousek z manuálu, co jsem zkopíroval, říká, že pokud použijete trigger AFTER UPDATE|INSERT, tak vám ovlivní jen řádky, které byly opravdu změněny, kdežto trigger BEFORE UPDATE|INSERT se bude trpět stejným nešvarem jako timestamp
matak
Profil
1. innodb a myisam, to je asi na jinou diskusi, ale jednoduše si databázi bez cizích klíčů nedokážů představit, pokud nejde o nějaké to logování prokliků apod. miliony záznamů, každopádně můžeš uvést příklad

2. triggery minimální režie, no je to o tom, že u 100000 řádků proběhne 100 000x foreach pro každý řádek a projede všechny sloupce a porovná hodnoty, zda se nezměnili, tak nevím, ale to se musí celkem podstatně projevit, to je můj názor

3. after a before update asi u mne horší angličtina,

a BEFORE INSERT trigger will activate for every row, followed by either an AFTER INSERT trigger or both the BEFORE UPDATE and AFTER UPDATE triggers, depending on whether there was a duplicate key for the row.

jaký by byl přesný překlad?

followed by either an AFTER INSERT trigger or both the BEFORE UPDATE and AFTER UPDATE triggers

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: