Minutový záznam – MySQL – Fórum – Programujte.com

Dobrý den,
napadá mne mnoho řešení a tak se ptám zde - jak nejlépe vyřešit umazávání řádku v databázi? Totiž mám jednu databázi - ve které si uživatelé ukládají své příspěvky - ty mohou poslat do druhé každou hodinu (a toto posílání naplánovat dopředu - vytvořit si frontu posílání do fronty) - ve které až přijde jejich příspěvek na řadu, se po minutě smaže - čímž se dostane na řadu další... Oddělení do dvou DB má přávě ten smysl, že druhá databáze bude jen na toto mazání po minutě... První databázi spravují sami uživatelé - tedy kromě toho, že se musí nějak vyřídit jejich fronta. (ddd příspěvek chci za hodinu, eee příspěvek za 2 hodiny, iii příspěvek za 3 hodiny poslat do druhé DB...) Druhá se zdá být jednodušší - stačí jen každou minutu smazat první/poslední řádek... (dle toho, jak se budou příspěvky hromadit)
Děkuji.

O můj bože! Tak jednoduché - přivedl jsi mne na myšlenku - žádné přesuny, nic - so easy! Děkuji! :D

(každý příspěvek bude mít počet přidání do fronty - časový údaj posledního přidání a tak jen projedu všechny příspěvky s příznakem fronty...)

Tak přeci to není tak jednoduché. Vytvořil jsem pohodlný systém, jak zobrazit aktuální příspěvek z fronty + čas, kdy bude fronta vyřízena a tudíž čas, ve kterém přijde na řadu nově přidaný příspěvek... Jenže pořád nemám ono vyřizování fronty. Tedy potřebuji aby se při požadavku "get" (větev switch) nejen vytáhl příspěvek, který je na řadě (což mám nyní), ale také, aby se fronta posunula, je-li čas. S prvním SELECTem ve frontě má začít odpočet jedné minuty následovaný smazáním vrcholu fronty. Napadá mne jen velice složitý model, jak toho dosáhnout. Zahrnuje i znovuvytažení vrcholu fronty, když zjistím, že aktuálně vytažený příspěvek je už prošlý... Zkrátka - nešlo by to čistěji? Něco spustit na serveru? Problém mi činí také to, že existuje cca. 300 front... (to co bych spustil na serveru by muselo spravovat 300 různých vrcholů front - a nenapadá mne způsob, jak udržet ten minutový systém - leda 300 vláken - a to je moc kruté...) Sám uživatel si volí, z jaké fronty chce vidět aktuální minutu - aktuální příspěvek...

sprav tu frontu ako linked list ... bude to len jedna tabulka pricom kazdy zaznam bude zaroven odkazovat na predchadzajuci a nasledujuci (can be null - null means end of line) ... pri odstranovani sa nesnaz drzat eager sposobu ale skus to spravit lazy (usetris si vela problemov s casovacom a tiez vytazenost) - zaznam nebudes vyhladavat aktivne ale ked narazis na to ze zaznam nema existovat tak sa posunies na zaciatok danej fronty (dolezite pretoze ak by si vymazal prispevok len tak tak by si vytvoril dve nove fronty - jedna by koncila pred vymazanym zaznamom a druha by zacinala za nim ... musis nastavit na dany foreign key aby sa cascadoval na null inak by si mal nestabilnu tabulku ... zaroven si vyskusaj ci sa ti oplati dat index na foreign key alebo nie) a zacnes vymazavat az kym nenarazis na prispevok ktory ma existovat (pouzi vlastnost TimeToLive - tymto mozes nastavit pre rozne prispevky roznu zivotnost)

Jak mám udělat takovýto systém, když to uživatelé utvářejí frontu? Mám nyní tabulku queue. V ní id záznamu (primární klíč), id fronty (těch je cca. 300) a časové údaje - vznik a po prvním přečtení zánik (can be null - před prvním SELECTem). Maži podle id záznamu... (uživatel může svůj příspěvek odstranit z fronty - rozmyslet si publikaci příspěvku) Tudíž si nedovedu představit, jak propojit všechny příspěvky jedné fronty - leda 300 tabulek... (takto je jen 300 ID regionů - front) Když se uživatel rozhodne, že chce vidět příspěvek z fronty, pak jen upřesním WHERE...

jedna tabulka = jeden objekt = jedna funkcnost ... jednu funkcnost rozdelovat do viac tabuliek je casto nezmysel

fronta ti vzdy zacina na prispevku ktory nema ziadneho predchodcu a konci na prispevku ktory nema ziadneho nastupcu ... takto mozes mat nekonecne mnozstvo front v jednej tabulke ... jednotlive fronty budes rozdelovat podla stlpca s foreign key na inu tabulku ... ak sa rozhodnes vymazat prispevok zo stredu tak proste musis ist na prispevok predchadzajuci a napojit to na prispevok nasledujuci (a naopak) - potom mozes odstranit dany prispevok na ktory nic neodkazuje

Můžeš mi ukázat, jak přidat nový záznam - s id fronty atd. prosím? Kukám  nyní hodiny do návrháře a prostě netuším jak s tím hnout... (zkoušel jsem propojit kde co)

Nyní mám:

$databaseQueue->insert(array
(
	"region" => $_GET["region"],
	"ad" => $_GET["ad"],
	"author" =>$author
));

To znamená obyčejný INSERT... U toho tvého bych musel vytáhnout spodek fronty...

#7 Flowy
Implementovat frontu na relační databázi je poněkud nešťastné řešení, protože relační databáze na tento způsob práce nejsou stavěné.

Pokud znáš id předchozího prvku, tak můžeš použít SQL dotaz: 

SELECT * FROM fronta WHERE id IN (
    SELECT min(id) FROM fronta
        WHERE id>$stareId AND jmeno_fronty='tuhle_chci'
    );

Pak tedy - jak jinak bys ty udělal frontu, která bude publikovat každou minutu příspěvek z MySQL databáze? (v záznamu fronty je ID příspěvku, který chceme publikovat)

id, stav, time, ...
INSERT ... stav=0, time=NOW()
SELECT * ... stav<>0 OR time NOW()-1min
Cili, muzes to dat rucne publikovat pres zmenu stavu nebo po minute se to bere uz jako publikovane samo.

jo, time>NOW-1min (mozna mensi, u casu ted presne nevim). A odcitani je SUBDATE.

Ale jak se mi uloží stav? Důvod proč to nedělám jak jsem napsal - že bych uložil čas při prvním SELECTu (NOW()) a pak v PHP dopočítával minutu je ten, že k tomu přistupuje mnoho lidí. Tudíž by při souběhu docházelo k tomu, že si 2+ lidé vytáhnou starý záznam, zjistí že už je po 1 minutě publikace a tak oba vyberou nový - pokud bude jeden rychlejší, další skočí o 2, místo o 1... Toto by sice vyřešilo zmíněné provázání všech postů fronty, ale u tohoto postupu se mi stále nedaří navázat kontinuitu. Navíc samotné neustálé kontrolování aktuálnosti - rád bych udělal možnost zkouknutí fronty - aby si lidé mohli promyslet, zda se jim vyplatí na nějaký post čekat. A to právě byl můj dotaz zde:

http://programujte.com/forum/vlakno/27305-vice-pristupu-zbytecna-data

Musel jsem od toho upustit, jelikož by to vyžadovalo sekundové koukání do DB - protože každou sekundou se může někdo odhlásit z fronty atd. Právě pro tu potřebu dynamiky si dobře uvědomuji, že databáze není moc vhodná... Uvažuji nyní nad WebSockets. Ale stejně se ni nedaří vyřešit úplně vše - každé řešení má chybu...

Tebe zajimaji vsechny prispevky, starsi 1 minutu a vice. Cili vyberes cas, ktery je mensi nez NOW-minuta (coz resi SUBDATE nebo INTERVAL).
Pokud budes chtit zobrazovat 10 lidem aktualni prispevky kazdou 1s, tak musis posilat dotaz na server (cili takovy chat). Chat ja resim tak, ze interval je 17s pro autorefresh a refresh pri vynuceni (pridani noveho radku). Kdyz by treba 3x probehlo 17s, tak bych mu dalsi refresh udelal as za 1-2 min a pripadne pak uz jen 5 min. Tim nebudu zatezovat server, kdyz ten clovek jenom okno prohlizi a na nic neklika, nic neposila.
Stav prave resi situaci, kdy chces ten casovy limit obejit, aby se to zobrazilo hned.

Jak jsem psal - to je utopie. Spíše nyní přemýšlím nad WebSockets. Pořád hlavně nevím jaké použít úložiště... Při WebSockets by se server nemusel potýkat se souběhem, jelikož by se změny projevily jednoduše posloucháním v JS... Co ale řeším - jak spravovat 300 front... Jak jsem psal - napadá mne řešení jedině s více vlákny. Ale 300 vláken? Anebo 300 spuštěných programů - opět utopie...

#15 Matěj Andrle
A ty si myslíš, že 300 dotazů za sekundu je pro databázi problém? Tak si vyber jinou databázi, třeba Redis. Ta na mém Atomu zvládne několik desítek tisíc transakcí za sekundu, na serveru to budou stovky tisíc.