PISKVOR: ještě by to samozřejmě šlo i bez joinu - prostě si vyjedeš nové příspěvky do pole + lidi v ignore/lidi co mě mají v ignore a z prvního pole smažeš ty, co k tomu patří

SWT: Já taky nejsem žádněj DB Guru™; hodně záleží na tom, jak jsou ty tabulky navržený. Jak říkáš, to už je spíš na NYXe.

PISKVOR: Nerozporuju, nicméně pokud jsem do čehokoliv přidával tabulku (zejména tahle situace, kdy redukuješ velikost výslednýho resultsetu), tak jsem se (i s tabulkami s 1M+ záznamů) nedostal na nárusty costu větší, než desetiny procent ... takže moje zkušenost z mý praxe je, že "tabulka není žádnej problém" ... proto jsem se začal ptát NYXe, proč to problém je, protože samozřejmě moje zkušenost je velmi omezená a rád se dovzdělám, což už tvý příspěvky iniciovaly.

PISKVOR: Ale to už jsme hluboko v oblasti spekulací...

SWT: To je relativní - "první v závodě šneků je sice nejrychlejší, ale pořád šnek." Že tam moc costu přibejt nemůže...ale může, to by ses divil. Nebo taky nemusí - záleží na velikosti tabulek, indexaci, velikosti resultsetu, podmínek joinu, řazení, sargabilitě etc etc etc.

PISKVOR: To chápu :) Nicméně dle mých chabých zkušeností je join s tabulkou (a ingnore je IMHO určo v tabulce) asi to nejrychlejší, takže IMHO tam moc costu přibejt nemůže :))) ale jsou to samozřejmě pusté spekulace bez znalosti vnitřností NYXu.

SWT: To právě nejde říct takhle obecně; může to znamenat nárůst zátěže o promile nebo o stovky procent _i v rámci toho jednoho dotazu_, protože tam je hromada proměnných.

PISKVOR: OK, díky, přesně kvůli takovýmhle různým úhlům pohledu a aspektům jsem se ptal. O AJAXu toho bohužel mnoho nevím, takže netuším, jak by se to projevilo nebo jak by se to dalo efektivně řešit.
Dotazů bude lítat furt stejně, ale přiznávám, že neumím říct, jaký nárust zátěže by to přidání joinu představovalo (resp. jak se takovej ztěží měřitelnej nárust v rámci jednoho dotazu promítne multipikovaně v těch množstvích).

vsechno jde, kdyz se chce...

SWT: Psal _rozumne_ neslo - tipuju "protoze by to delalo silenej napor na databazi." Byt je to (odhadem) jeden join navic, dela se 1.pro kazdyho uzivatele x auditko jinak, a hlavne 2. dotaz, ktery se dela pro _kazdy_ okno, ve kterym je otevrenej nyx (a uzivatel nema vypnuty online notifikace), takze techto dotazu bude litat X za sekundu (desitky? stovky? tisice?).

Jediny, co me napada, je drzet si ten seznam ignoru v browseru, a pokud IDcko v nem je, tak ho nezobrazit; ale to uz je kousek za hranou me predstavy "rozumnosti."

NYX: Z chorobný zvědavosti - proč by to nešlo, vyřezat z libovolného seznamu nicků (zde ikonek kdo přispěl) nicky, který jsou na jiném známém (ignore) seznamu?

hlavně by to chtělo u oboustranného ignore nastavit správně i ajaxy

když jsem v auditku a reaguje tam osoba, co si mě dala do oboustranného ignore, tak nahoře vidim její ikonku, že přispěla do auditka

LODBROG: To uz mam doma opravene, nasadim az se vratim

Opět něco špatně při ukládání příspěvků do bloku - původní příspěvek to uloží, ale když ho chci editovat tak to křičí kvůli nepovoleným atributům (tuším že hlášení datumu).
Takže se v tom člověk musí vrtat a růčo ty atributy u všech příspěvků umazávat, aby to šlo uložit.

OVECKA_MJ: kouknu na to pristi tyden

Nemusel se spíš povolit PRISMu ? :)

k čemu to bonzování vlastně slouží ?