spájame
slovenskú
IT komunitu
pridaj sa
Registrácia · Login
Zajtra.sk > Fórum > Zajtra.sk - pripomienky a návrhy > Páči/nepáči na komentároch - zobrazovanie mien užívateľov?

pridal -
2.10.2012 17:38:30

Páči/nepáči na komentároch - zobrazovanie mien užívateľov?

Myslím, že by stálo za zváženie zobrazenie užívateľských mien užívateľov (teda napr. "mhp", "Monča Holčeková",...) hodnotiacich komentár, napríklad v štýle FB. Jednak by to napovedalo viac k prebiehajúcej diskusii (teda kto s čím súhlasí/nesúhlasí), takisto by to mohlo pomôcť vyjasniť, aká skupina ľudí má aký postoj (napr. ak s komentárom súhlasia ľudia, ktorí majú skúsenosti v danej oblasti, má to predsa trochu inú váhu ako keď súhlasia laici) a v neposlednom rade som si všimol minimálne raz rýchle "omínuskovanie" všetkých názorov v diskusii (teda aj opačných), čo podľa mňa zaváňa "trolling"-om (i keď môže ísť len o zhodu okolností...).

No a nakoľko to je komunitný portál, myslím, že nie je čo skrývať :). Čo si o tom myslíte?

50 komentárov

Komentovať môžu iba prihlásení

Zaregistruj sa cez bezplatnú registráciu alebo použi login cez Facebook (FB Connect)

Prihlás sa tu, ak už máš profil na Zajtra.sk:


Zabudol som heslo

0 0 Mária Drozdík 1.6.2019 10:18:26
Potrebujete finančnú podporu pre rôzne projekty? Už žiadne starosti. V spolupráci s bankou Slovenskej sporiteľne ponúkame úvery akejkoľvek osobe alebo spoločnosti v núdzi. Naša úverová kapacita sa pohybuje od 5 000 do 100 000 eur pri primeranej sadzbe 1,5%. Ak máte záujem o úver, kontaktujte nás prosím na: E-mail: drozdikmariakontakt@gmail.com
0 0 Peter Širka 14.10.2012 10:38:19
@- prečo si taký vzťahovačný? Čakal som, že dôjdeme k spoločnému riešeniu toho, čo si načrtol v diskusii nižšie. Škoda...
0 0 - 13.10.2012 17:01:37
@Peter Širka "si veľmi tvrdohlavý" - vidím, že ma "poznáš". Aj keby si mal mať tento dojem z diskusie, je to odbočka od témy k nabúravaniu sa do niekoho (samo, to isté teraz robím aj ja a aj preto nebudem pokračovať v debate). Čo sa týka ďaľšej konverzácie, končím, ja si myslím, že som svoje dôvody dostatočne opísal nižšie, ak to nie je z toho pochopiteľné, buď to neviem lepšie vysvetliť alebo niečo bráni pochopeniu, neviem, nechcem sa do niekoho navážať.

Ide o konkrétny príklad, kde sa to používa často a je relatívne nízky počet LIKE/DISLIKE (rádovo ako je tomu teraz). Myslím, že počet dopytov je jednoduchá matematika a aj záťaž, ktorá s tým ide ruka v ruke. Ba dokonca som nižšie uvidol príklad, kedy je vhodnejšie riešenie s AJAXom. Viac už nemám čo dodať (a ani sa mi nechce).
0 0 Peter Širka 13.10.2012 12:37:49
@- skomolil som ti meno :( prepáč ... @admin v diskusii nejde ešte upraviť komentár.
0 0 Peter Širka 13.10.2012 12:35:55
@mph - nikto ťa tu neuráža! Ja som dal ďalšie riešenie a napísal som, že prečo, načo, začo. Problému som sa venoval oveľa viac ako ty. Napíš, prečo práve to tvoje riešenie je lepšie (možno prídeme na to, že čo som napísal ja je fakt hlúposť - veľmi rád si priznám chybu!). Môžeme to aj otestovať. Budem sa ti snažiť dokázať, že moje riešenie je jednoduchšie a efektívnejšie ... a dokážem, že tvoje riešenie je komplikovanejšie a z pohľadu budúcnosti aj neefektívne, priam likvidačné.

@Milan Vodička - @mph a @J chcú načítanie LIKE&DISLIKE pri komentároch riešiť už pri načítaní stránky. Ja by som bol za riešenie cez AJAX (ako @Peter Payter Gašparík). Hidden field sa myslí nižšie uvedený príklad:

Viditeľné elementy:

--- 1. KOMENTÁR (1 LIKE, 4 DISLIKE)
--- 2. KOMENTÁR (0 LIKE, 3 DISLIKE)
--- 3. KOMENTÁR (0 LIKE, 0 DISLIKE)
--- 4. KOMENTÁR (5 LIKE, 3 DISLIKE)
--- 5. KOMENTÁR (3 LIKE, 8 DISLIKE)

HIDDEN FIELD by obsahoval nejak serializované data (napr. JSON):

1. KOMENTÁR
Peter Širka, dal LIKE
Shaggy, dal DISLIKE
Tester, dal DISLIKE
mph, dal DISLIKE
niekto, dal DISLIKE

2. KOMENÁR
Peter Širka, dal DISLIKE
Shaggy, dal DISLIKE
Tester, dal DISLIKE

... atď.
... ak to chceme robiť poriadne, treba uložiť ešte k užívateľovi odkaz na jeho profil a jeho fotografiu, takže tie DATA ešte viac narastú. Hádam ma chápeš.
0 0 - 13.10.2012 11:55:25
@Peter Širka zda sa mi, ze si mozete podat ruku s @Peter Payter Gašparík , lebo pri vrcholeni diskusie ste obaja isli k podryvaniu druhej strany/urazani namiesto venovaniu sa problemu a uvedeniu prednosti svojho riesenia pre konkretny priklad.
0 0 Milan Vodička 13.10.2012 11:54:20
@Peter Širka "Pri dynamickom texte .... ak si toto fórum prečítaš 50x, tak tá veľkosť ti trošku narastie v hidden datach, pri 100 ľuďoch to budú aké násobky?" o ake hidden data ide? Trosku som nepochopil.
0 0 - 13.10.2012 11:49:09
@Peter Širka hej, v mojom svete je zatial menej requestov menej zatazujucich, za tym si stojim ;).
1 2 Peter Širka 13.10.2012 11:10:10
@- nikto tu nechce optimalizovať pre 500 LIKE&DISLIKE. Riešenie ktoré som uviedol ti vyrieši aj tento problém. Takže ak raz urobíš niečo poriadne, nemusíš sa už k tomu vracať (a budeš to aplikovať aj na ďalšie projekty). Teraz som čítal históriu a zistil som, že ty si nositeľom myšlienky PER REQUEST. @Peter Payter Gašparík sa ti zo snažil vysvetliť, ale ty ako keby si to nechcel pochopiť, si veľmi tvrdohlavý. Krásne si to napísal: najjednoduchšie riešenia bývajú tie najlepšie (bohužiaľ je ich najťažšie urobiť). Samozrejme v dobrom :-)

@J obrázok vieš krásne vy-cacheovať. Takže pri dobre optimalizovanom webe data sťahuje len raz. Pri dynamickom texte .... ak si toto fórum prečítaš 50x, tak tá veľkosť ti trošku narastie v hidden datach, pri 100 ľuďoch to budú aké násobky? 500 LIKE&DISLIKE bol len príklad. K DDOS by sa divil aké jednoduché je ho urobiť ... Iba hlupák sa učí na vlastných chybách - a ja som bol veľký hlupák. Mal som šťastie, že toto ma naučil sám život, nie každý bude mať také možnosti, ako som mal ja.

-------------------------------

Každú stránku treba optimalizovať. Väčšinou na hostingoch beží X stránok a X databáz. Ak už jeden kóder začne flákať svoju robotu, potom to má dopad na všetky stránky a databázu. Prajem každému z Vás aby ste mali vlastný server (ktorý si mesačne financujete) a na ňom viacej stránok, vtedy pochopíte čo znamená nájsť efektívne riešenie na to, aby som nemusel kupovať ďalší server.
1 0 - 12.10.2012 12:54:53
sry, nechce sa mi to komlpet citat, len moj dojem z toho, co som preletel: mne sa zda, ze sa moc necita/neuvazuje v tom, z coho vychadzame. riesenie je prirodzene odlisne pre 500 like/dislike - tam ani nema zmysel vypisovat mena, takze tento smer uvazovania mozeme komplet zahodit. riesime situaciu: bude sa to pouzivat casto a ide o objem like/dislike podobne ako je tomu teraz. nema zmysel riesit 500 like/dislike, ani situaciu, ze sa to nepouziva, leda ze by sme sa chceli dohadovat.

ja vychadzam z nasledovnej situacie (ako som pisal nizsie): snazim sa riesit hrdlo flase za predpokladu, ze problemom je db, co sa stava pri vacsich projektoch, ked moze byt db napr. na inom servery (aj ked pochybujem, ze je to pripad zajtra.sk, ale o to ide pri takejto uvahe o rieseni - riesenie za urcitych predpokladov, pretoze pre rozne situacie je vhodnejsie ine riesenie). ak budem robit X requests, pricom pokazde potrebujem spravit ten isty JOIN, je to zbytocne zatazujuce. ako spravne niekto poznamenal nizsie, pri nacitavani stranky prebehne beztak tolko dopytov, ze tento je prakticky zanedbatelny a zatazajucejsie je X postupnych dalsich posielani dat.

teda, ked sa pozriete spat, vseobecne vznika nesuhlas v komentaroch, pretoze sa vychadza z inych predpokladov (moj dojem). niekto to chce optimalizovat na 500 likes, ktore pozrie malo kto, niekto pre objem, pri ktorom to ma este zmysel a za predpokladu, ze je to casto vyuzivana feature. kto ma pravdu? zalezi, co sa riesi. a prave o tom to je, navrhnut vhodne riesenie pre konkretnu situaciu.

moj postreh: nema zmysel optimalizovat na 500 likes, ked taka navstevnost a citatelnost je momentalne v nedohladne. IMO by malo technicke riesenie rast ruka v ruke s projektom, ako niekto poznamenal uz skor, predcasna optimalizacia je zdrojom zla a premrhanych hodin klienta, ktory to casto nevyuzije, nakolko sa vyuzitia projekt ani nedozije. najjednoduchsie riesenia casto (najma na zaciatku jednoducheho projektu ako zajtra.sk) byvaju tie najlepsie...
1 0 J 12.10.2012 12:38:00
ehm 500 like pri kazdom komentari? tu som ich naratal 4 na celej stranke :). Samozrejme ze pri 500 lajkoch na prispevok by riesenie muselo byt ine ale pokial sa bavime o zajtra.sk, tak s tym ddos si ma celkom rozosmial :).
Tie skryte data v ktorych by boli mena, kto lajkol prispevok by ani zdaleka nemali vacsiu velkost ako tvoj mini avatar obrazok 50x50 ;)
1 0 Peter Širka 12.10.2012 11:22:26
@Milan Vodička :

- áno, máš tabuľku komentáre a tá má stĺpec LIKE a DISLIKE
- potom máš tabuľku LIKE (aby sme vedeli, kto LIKE)
- ostatnú štruktúru budeme riešiť cez JOINy, či už s kľúčom alebo bez neho (kľúč sa dá určite dorobiť).

Jeden Request = VEĽKÁ CHYBA:
- jedným Requestom posielaš zbytočné data, lebo niekto nechce vidieť LIKE&DISLIKE mená (tým pádom jedným Requestom zaťažíš viac SQL, server a prenášaš oveľa viac dát). Čo ak budeš mať v komentároch pri každom komentári 500 LIKE&DISLIKE? Čo potom? Skončil si a server tiež (urobíš si vlastný DDOS). Čo ak ti navštívi stránku robot, ktorý ti bude prechádzať každý článok? Potom si tiež skončil. Prognóza zajtra.sk je rastúca návštevnosť, už teraz treba trošku na to myslieť.

Riešenie? Jednoduché, AJAX.
- cez JavaScript si pošleš do Requestu počet LIKE&DISLIKE k danému komentáru... na serveri budeš vedieť (ešte pred inicializáciou DB) aký počet LIKE&DISLIKE budeš z databázy ťahať, takže stránkovanie ti pôjde na jeden SELECT. Už z počtu LIKE&DISLIKE vieš zistiť koľko budeš mať strán mien LIKE&DISLIKE. A ak to nebude stíhať? Za-cacheuješ na niekoľko minút RESPONSE LIKE&DISLIKE (pri veľa len určitú stranu) a si za vodou. AJAXom vyriešiš aj internetové roboty.

Ja som v minulosti chcel riešiť veci podobne, ale naučil som sa na veľmi veľa projektoch, že sa to dá aj jednoduchšie.

Pre všetkých:
Server Scripting - Array alebo kolekcie nie je vôbec riešenie, je to len posunutie problému z SQL do kódu.

Ak má niekto ešte nejaké riešenie, veľmi rád si ho prečítam.
0 0 Milan Vodička 12.10.2012 10:49:38
@Peter Širka sry :), niekedy nechapem ani sam co som napisal. No pochopil som ta takto. Mas tabulku komentarov, kde kazdy komentar si uklada kolko ma lajkov(a dislajkov co sa mi nechce pisat) takze mas tuto informaciu viac krat v systeme. Potom mas tabulku lajkov, kde by si mal mat povedzme cas, priznak ci je to like/dislike a foreign key na tabulku uzivatelov a fk na tabulku komentarov. Ak by si tam mal len meno a nie fk, mas ulozene mena zbytocna viac krat.

Viac requestov, to je jasne. Keby si ale pouzil jeden request (vsetky komentare aj s likes), jedna instancia php by musela spracovavat viac dat a teda by zrala viac ram a bolo by to pomalsie. Zas na druhej strane ani to nemusi byt pravda, lebo kazdy ajax request znamena dalsi apache proces (alebo thread ak pouzivas iny sposob) a teda dalsia ram a vykon. Kde pri ajaxe vytazujes vsetky sietove prvky, ale pri nacitani vacsieho objemu dat z DB ti to v niektorych pripadoch moze byt jedno.

A teraz, ak mas ForeignKey na tabulku komentarov, pouzije sa ako index samozrejme, co si aj hovoril, ale ja som sa zamotal :D. Ak by si pouzil povedzme v mysql myisam engine, musel by si ten index explicitne declarovat, lebo myisam nevie pouzivat FK ak sa nemylim.
0 1 Peter Širka 12.10.2012 10:39:54
@Milan Vodička to nemôžeš použiť iný výraz ako redundacia? Musel som to lúštiť cez Google :-)

Vieš mi do-vysvetliť, ako si myslel toto? Možno som vypadol z kontextu, tak sa ospravedlňujem.

Akurat mas redundanciu dat, niekolkonasobne viac requestov a ked nepocitas s joinom medzi lajkami a uzivatelmi (co som vycital podla pouzitia indexu, ktory by bol inak pk/fk), tak este vacsiu redundanciu dat. Ale server script nezere tolko pamate. ... S joinom medzi like&dislike a užívateľmi rátam a ostatné chcem ešte do-vysvetliť ak sa dá, ďakujem.
0 0 Milan Vodička 12.10.2012 10:29:36
@Peter Širka krajsie by bolo pouzit pri vkladani like/dislike trigger na pripocitanie poctu (ak ti to hosting dovoli).

Akurat mas redundanciu dat, niekolkonasobne viac requestov a ked nepocitas s joinom medzi lajkami a uzivatelmi (co som vycital podla pouzitia indexu, ktory by bol inak pk/fk), tak este vacsiu redundanciu dat. Ale server script nezere tolko pamate. Podla mna to je jedno ako by to vyriesili na zajtra.sk, ale keby sa islo do extremov, zalezalo by na architekture. Ak mam povedzme php a db server meter od seba na rovnakej sieti, je mi skoro jedno kolko dat prenesiem oproti poctu requestov, ktore by sa museli vykonat, ktore vytazuju celu siet od klienta az ku mne. Teda aspon mam taky pocit v kostiach :D
0 0 Peter Širka 12.10.2012 09:50:56
@Michal Obeda presne tak. Pri článku si dáš vypísať komentáre a nemusíš rátať každým SELECTom počet Like a Dislike daného komentáru, lebo ich máš uložené pri komentári. Po kliknutí na zobraziť mená Like&Dislike pošleš Request na server a podľa indexovaného kľúča (aby to bolo rýchle) IdKomentar dáš vytiahnúť všetky mená a k ním bool Like or DisLike.

Výhody:
- každý nebude klikať na zobraziť mená like&dislike, ušetríš záťaž
- nemusíš načítavať kvantum dát a nezaťažíš pamäť a SQL
- jednoduchý SELECT komentárov (nemusíš pritom COUNTovať)
- vieš to krásne cacheovať

Nevýhoda:
- pri Like&Dislike musíš urobiť na vyše UPDATE komentáru
- treba upraviť schému DB (ak nie je)
- efektívnosť sa ti neprejaví teraz, ale dajme tomu ak bude v DB cez pár 10 000 záznamov to už bude určite citeľné.

Ak máš lepšie, efektívnejšie a tiež jednoduché riešenie sem s ním a môžeme kľudne urobiť testy. Ja môžem testovať na SQL SERVER -i. Toto sú best practice a rád sa poučím.

-----
Neviem ako pri MySQL, ale pri SQL SERVERI nejde urobiť v jednom vnorenom SELECTe 2 COUNTY, vysvetlenie:

SELECT Komentar, (SELECT COUNT(*) ... WHERE JeLike=1) As Like, (SELECT COUNT(*) ... WHERE JeLike=0) As DisLike ... neviem či sa chápeme... Myslím si, že rýchlejšie riešenie ako navrhujem nie je. Bodaj by som sa mýlil.
0 0 Milan Vodička 12.10.2012 09:42:31
@Miloš Ja som sa len pytal, ci to spravne chapem. No takze dostanes dve polia, v jednom budes mat likes a v druhom dislikes. Mne islo o to pokracovanie. Teraz mas pripravene dve polia a ides vypisovat komentare. Okej, iterujes cez komentare, vypises komentar a teraz k nemu potrebujes pridat likes a dislikes plus ich pocet. Budes pokazde prehladavat pole (jedno ci dve) a hladat sprave likes/dislikes?

Teoreticky keby bolo jedno pole zoradene podla casu a komentare su zoradene podla casu, staci prehladavat pole naraz s polom komentarov a usetris si kopec iteracii. (each()).

Aj tak ale potrebujes dva iteratory, ktore pocitaju likes/dislikes ku kazdemu komentaru. Ci?
0 1 Michal Obeda 12.10.2012 09:21:42
@Peter Širka - takže ty vravíš, že okrem samostatnej tabuľky by si ukladal počet like/dislikov k samotnému komentáru? To nie je moc správne riešenie.
A databázu chceš riešiť tak, že budeš ajaxom posielať veľa requestov? Nejak mi uchádza pointa, ale tu moc databázu nebudeš šetriť, skôr naopak (a to nehovorím o nadbytočných requestoch).
1 0 Peter Širka 12.10.2012 07:11:55
Chlapci vy čo riešite? Prečo to nenecháte na správcov? Aby som sa netváril ako nečinná osoba ... Podľa mňa dosť zle rozmýšľate, ja by som si každý like/dislike uložil do DB (tak ako to je) + aktualizoval vždy daný komentár o PočetLike a PočetDislike. Tým pádom nemusíš pri SELECTe komentárov COUNTovať like a dislike. Potom existujú aj indexy a cache, ale to je zbytočné na takú malú návštevnosť. Mená sa dajú krásne zistiť cez cez JavaScript. Stačí ti skontrolovať či, v HTML Like alebo Dislike je hodnota väčšia ako nula a ak je posielaš request na zoznam mien. Databázu treba čo najviac odbremeniť od bombardovania za každú somarinu, pri väčších projektoch by ste na toto doplatili.
0 0 Miloš 12.10.2012 00:41:47
Milan: A to je problém triediť ešte aj podľa like (1) a dislike (0) priamo v databáze pomocou indexov? Osobne mi je jedno, či budú mená alebo nie, ale zarazilo ma, prečo by sa to nedalo naraz vcelku prenechať indexom. Pri načítaní len prejdeš pole a keď narazíš na hodnoty 0, čiže dislike, tak začneš ukladať do druhého poľa (prípadne na hodnoty 1 - like, keďže indexy vedia triediť buď všetko vzostupne alebo zostupne.
Zajtra.sk > Fórum > Zajtra.sk - pripomienky a návrhy > Páči/nepáči na komentároch - zobrazovanie mien užívateľov?


Kritika

Vieš ako robiť veci lepšie? Pomôž našim odvážnejším členom a skritizuj im projekty!

Reklama

Seriály zo Zajtra.sk

Reklama