BURAN: doufam, ze ne

zajimave ID se zajimavou galerii. http://www.nyx.cz/index.php?l=galerie;l2=3;user=LED_SVETLA
bude podobnych pribyvat?

CRAZY_IVAN: Jak jsem psal tajdlenc, v posledni vete.

PISKVOR: ano, tak jsem to myslel :) a ono ta ignorovaná/kym ignorovanej IDčka uživatele můžeš mít uložené v hlavním okně nyxu a pak je posílat jako argument, abys je nemusel tahat z DB, sice je tam prostor pro díry, ale ušetří to (sice jednoduchej) dotaz na db

CRAZY_IVAN: Jinými slovy, spytlíkuješ si ten join mimo databázi, takříkajíc ručně. Taky možnost, ale dost hackovitá (byť v jistých mezních případech to funguje lépe, než to nechat na db).
ZUZKAOU: Teď jsem kouknul na login page, a nyx už není diskuzák - ale můžeme si tu prej poradit, pomoci, nebo se i pobavit. Že by to byl ten důvod snahy o nejsluníčkovitějšnost?

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