MYSQL úloha /problém

[Chris]

zdravim,

kedze je tu vela roznych manikov z roznych oblasti.

Mam nalsedovny problem v MYSQL :

Tabulky A a B, ktore vyzeraju rovnako a asi takto:

+------+-------+------+---------------------------+
| ID | A | B | Timestamp |
| 308 | 1.82 | 1.38 | 2012-08-28 21:17:59 |
| 309 | 1.81 | 1.81 | 2012-08-28 21:18:25 |
| 310 | 1.38 | 1.34 | 2012-08-28 21:18:43 |
+------+-------+-------+--------------------------+

data sa tam plnia kazdu sekundu a tabulka je prakticky nekonecne velka.

Potrebujem zosynchronizovat tabulky podla timestampu ( teda podla rovnakeho casu) to sa mi podarilo left joinom...

nieco podobne by som potreboval, aby ak sa napr. zapisu nove data v A tabulke, nech do novej C tabulky zapise nove hodnoty (A1-A2)

takto:

+---------------------------+--------+------+
| Timestamp |A1-A2 | B1-B2|
| 2012-08-28 21:17:59 | x | x |
| 2012-08-28 21:18:25 | x | x. |
| 2012-08-28 21:18:43 | x. | x |
+---------------------------+--------+--------+

viete mi niekto poradit, ako to spravit ? diky moc

[M1ch4l]

trigger

[steel]

Otazka je ake tam bude zdrzanie, ked sa mu to plni kazdu sekundu... Tak trochu to smrdi zlym navrhom aplikacie, ale to je len moj osobny dojem.

[Scorp]

trigger, ak tam nelieta moc insertov, bude to ok

[faugusztin]

nieco podobne by som potreboval, aby ak sa napr. zapisu nove data v A tabulke, nech do novej C tabulky zapise nove hodnoty (A1-A2)

Mozno sa mylim, ale nestaci ti view ? Ako casto sa bude citat z tabulky C ? Ako narocny je ten tvoj select ?

[Chris]

do SQL uz moc nevidim, mal som semester , ale to je par rokov dozadu, mozno pomoze ak lepsie opisem moj problem a nakoniec z toho vznike aj nove riesenie

takze vstupy:

moje aplikacie posielaju cez 3306 port niekedy za sekundu aj 5-6x a niekedy len jeden riadok za 5-6sekund, to chcem odstranit, cyklom, ktory bude posielat len kazdu sekundu a vytvori tabulky A pre jednu aplikaciu a tabulku B pre druhu aplikaciu.

vystup:

v prvej faze ide o to, len zobrazovat data a to POSLEDNY UDAJ => rozdiel poslednych pridanych dat do tabuliek A a B.
Teoreticky by netrebalo prepocitavat celu tabulku, len napr. posledny alebo poslednych par udajov.
Tento posledny udaj teda rozdiel A1-A2 a B1-B2 by sa mal zobrazovat cez PHP na stranke v tabulke


2. faza kde by bol triger, kde po kazdom zapisani hodnoty do C , by sa spustil cyklus ci splna podmienku a aktivoval ine veci.... ale momentalne ma zaujima prva faza.


za vsetky odpovede vopred diky

[Scorp]

i dont get it úplne...ale teda

asi by som tie tabule A/B dal do jednej, robiť join podľa času nie je top nápad

potom ak máš ako primary key id s auto increment, posledný údaj zistíš ako

"select * from tabulka order by id desc limit 1" , alebo dotaz s id = max(id)

ešte sa dá robit "select last_insert_id()" , ale ten vracia posledný insert globálne

príp. to radiť podľa toho datetime, ale to je zlo,zlo,zlo .)))

[Chris]

takze este raz:

mam 2 aplikacie, ktore su podobne, ale posielaju rozdielne data, osetrim cyklom, aby posielali kazdu sekundu, lb inak data posielaju nepravidelne.

Potrebujem hlavne, posledne hodnoty, ALE ktore prisli v rovnaky cas a tie porovnat, respektive vypocitat ich rozdiel a tie dat tabulky v php.

Alebo neexistuje nejaky typ tabulky, kde by sa v riadku stale prepisovali len posledne hodnoty (ako napr. dakej premennej)
Alebo vytvorit nejaku memory tabulku, aby to slo rychlejsie.

1. Riesenie by bolo aj cez posledne ID, lenze, ak by bola jedna aplikacia vypnuta a druha by bezala, tak by porovnavalo stale posledne pridanu hodnotu, ktora by sa stale menila s hodnotou druhej tabulky, ktora bola posledna pred vypnutim aplikacie.

2. do jednej tabulky by to mozno slo dat, ale nevedel by som zarucit , aby sa v riadku ocitli hodnoty z tej presnej sekundy, teda doslo by k nepresnostiam, co by bol problem

lamem si s tym uz hlavu skoro 4 dni a niet boha prist na riesenie

[faugusztin]

Vsak ti hovorim sakra. Sprav view s joinom tych dvoch tabuliek, order by cas desc, limit 1 a mas tvoju jednoriadkovu tabulku, ktora ti pri kazdom dopyte bude vracat posledny stav, kedze bude vzdy prebiehat join tych tabuliek. Problem je, ak bude to query pomale pri velkej tabulke

[Chris]

nazdar, sry ale az teraz som sa k tomu dostal, spravil som ako vravis, lenze nastal problem ako si spominal

tabulka ma zatial len cez 600 zaznamov a uz to trva 5-6 sekund co je vela....

1 row in set (5.51 sec)

lenze tie tabulky budu mat kazdy den coraz viacej (denne 86400, kazdu sec 1 zaznam)

nedalo by sa spravit

moznost c.1;
2 MEMORY tabulky ( pre kazdu 1 ), do ktorych by sa insertovali data a spravit nejaky trigger, ze po kazdom zapise, by sa stare data presunuli do archivacnych klasickych tabuliek, view by sa spravil z tychto memory tabuliek

moznost c.2;
neinsertovali by sa data, ale by sa len prepisoval stale jeden zaznam, sice by to nevyriesilo problem s archivaciou, ale ani by to nemalo byt pomale..

alebo nejaka ina idea ? thx a lot

[Scorp]

máš niečo špatne, keď inserty trvajú 5s

nepotrebuješ memory tabuľky, brzda budú tie joiny
kľudne by som držal dve mega veľké tabuľky a spájal v nich posledných 100,200, whatever záznamov, buď joinami dvoch selectov s order by id a limit, alebo proste priamo v app, no science .)

tiež tam nepotrebuješ potom nikde indexy okrem primary key

príp. sem hoď my.cnf, že prečo sa vlečú tie inserty

[Chris]

nie inserty trvaju dlho, ale ten view s joinom trva tolko....

insert trva 0 skoro stale.

[Scorp]

tak urob select posledných 100 z A aj B a joinuj len tie

[Chris]

viacero selectov ide joinovat? pls example

[Scorp]

SELECT *
FROM
(SELECT * FROM tabulaA order by id desc limit 100 ) as A
join
( SELECT * FROM tabulaB order by id desc limit 100 ) as B
on A.cas=B.cas

nejak takto snáď