Starší komentáře ke článku: Strukturovaná diskuse pod články - teorie
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 22.7.2005 0:35:03
Nečítal som to síce úplne podrobne, ale zaujímalo by ma čo je N v zložitosti. Počet príspevkov? Čo je potom k? Inak takto som to riešil a riešim ja v podobných prípadoch. http://www.sitepoint.com/forums/showthread.php?t=215857
Datum vložení: 22.7.2005 1:04:55
Nevím, do jaké míry jste obeznámen s časovými složitostmi algoritmů... V algoritmech většinou zanedbáváme konstanty, což je to to "k". Například pokud cyklus projdeme dvakrát, bude složitost 2*N, ale my napíšeme jen O(N). O časové či pamětové náročnosti algoritmů bych chtěl psát později...
Datum vložení: 22.7.2005 8:41:00
Analýza a zložitosť algoritmov mi nerobí problém. Len som nikde v článku nenašiel čo je to "N" a čo je to "k". To môže byť všeličo. Preto sa pýtam. Inak myslím, že to moje riešenie bude v podstate presne to čo tu píšete. Taktiež má lineárnu zložitosť. Prechádzam celé pole komentárov/príspevkov len raz. Ale ak to bude vysvetlené v neskorších článkoch tak nechcem predbiehať.
Datum vložení: 22.7.2005 14:08:00
Jj, ja to tiež riešim rekurziou - je to jednoduchšie, myslím, že to nie je ani náročné (samozrejme, pokiaľ sa jedná o diskusiu s nízkym počtom príspevkov). Rovnako aj v prípade menu.
Datum vložení: 22.7.2005 8:32:20
Myslel jsem ze je to navod, jak se ulozi maticena sledniku prvniho radu ? Nebo se vzdy vytvori znova? Pokud to chapu dobre a vezmu fakt ze mam v db prispevky + matici, vychazi mi pro to ze stejne udelam N selectu je to tak (vzdy budu hledat prispevek s ID co je prave narade)???
Datum vložení: 22.7.2005 9:25:40
Hmm, jako mnohem větší problém než řazení příspěvků je jejich zatřídění podle vztahu k tématu. A na to nám asi žádné algoritmy nepomohou. V téměř každé diskuzi se objeví: 1) Příspěvek poukazující na gramatickou chybu v článku. 2) Nejméně deset příspěvků diskutujícím o tom, jestli to je gramatická chyba nebo ne, případně, že upozornění na gramatickou chybu do diskuze nepatří. 3) Aspoň jeden příspěvek poukazující na to, že autor zvolil nevhodný název článku. 4) Nejméně deset příspěvků vyjadřujících souhlas s tím, že název článku je opravdu nevhodný (kupodivu ani jeden příspěvek, který by název článku hájil). 5) Aspoň jeden příspěvek o tom, že kdyby uživatelé místo Windows používali Linux, tak by se jim to nikdy nemohlo stát (to = jakýkoliv problém zmíněný v onom článku). 6) Asi dvěstěpadesát příspěvků střídavě hájících Windows nebo Linux a napadajících to druhé. 7) Aspoň jeden příspěvek obsahující reklamu na cokoliv, co vůbec nesouvisí s tématem. 8) Dalších deset příspěvků, posílajících autora té reklamy do (CENSORED). Atd. atd... Bohužel, diskuze pod články jsou čím dál tím větší humus, viz například informace pana Klímy o kolizích MD5 na root.cz. Z těch asi 150 příspěvků byl jen jeden (!) opravdu k problému. Člověk by opravdu potřeboval vidle, aby se tím proházel k něčemu zajímavému. Tohle asi bude v budoucnu pro redakční systémy daleko nejdůležitější úkol a přiznám se, že zatím nevím, co s tím, snad kromě moderátora, který tyhle věci opravdu spravedlivě vyháže...
Datum vložení: 22.7.2005 18:35:55
Máte pravdu, obsah diskuse je problém. Ale nikoli problém pro redakční systém, alespoň dokud se nedostaneme k tomu vysněnému sama sebe strukturujícímu sémantickému webu. Do té doby je na lidech, aby udrželi úroveň diskuse. A přitom na to existuje jednoduchý recept - číst a mazat, jako tady na Intervalu ;-)
Datum vložení: 29.7.2005 10:54:04
Na popisovany problem by sa hodil system zalozeny na Bayesovi. Napr. blogovaci system Plog ho ma implementovany "od vyroby" :). Keby som to vedel alebo keby som ho mal pred rokom, nemusel som Bayesa mesiac kodovat sam :).
Datum vložení: 22.7.2005 9:25:53
Hned v úvodu článku bych očekával informaci, že tohle je jenom jeden z možných způsobů, jak se stromovými daty pracovat, obzvláště když na toto téma nedávno vyšel na Intervalu článek: http://interval.cz/clanek.asp?article=3801. Navíc je tento způsob ještě poněkud krkolomný, článek je velice nepřehledný (nebo to autor vzal za špatný konec).
Datum vložení: 22.7.2005 9:46:12
Je to pouze teoreticky vysvětlený princip. K příkladu s databázemi - pokud nepoužijete zásobník, tak máte celkem dost dotazů, což asi není úplně nejvhodnější ;) Přidávat zase zbytečně dva sloupce do databáze je zase imho plýtváním místem ;) Neříkám že moje řešení je jediné možné, ale myslím, že je celkem efektivní ;)
Datum vložení: 22.7.2005 11:44:23
Riesenim by mozno boli rekurzivne selecty v databaze, napriklad tak je to podporovane IBM DB2
Datum vložení: 22.7.2005 11:55:33
Skús si pozrieť ako som to riešil ja. Linka je v prvom komentári. Stačí jeden select a lineárny algoritmus na vytvorenie pekného poľa/stromu. Výpis je triviálna záležitosť.
Datum vložení: 23.7.2005 23:21:12
Řešení je to určitě zajímavé, ale nevím, jestli užitečné. Napsat velmi jednoduchou rekurzi, nebo načíst pro zmenšení počtu SQL dotazů příspěvky nejprve do pole a pak s nima pracovat mi přijde lepší, než tohle. Proč? Protože je to jednodušíí a proto, že dobrý programátor by měl počítat s tím, že ať se snaží jakkoli, bude vždycky rychlejší tahat stránku z keše a přegenerovat ji, jen když je třeba. Vymýšlení a realizace takových skriptů je sice zajímavé pro mozek, ale velmi kontraproduktivní. (neboli není efektivní)
Datum vložení: 24.7.2005 0:34:21
Koukám, že jste si asi nepřečetl pořádně celý článek. Náš postup de facto jisté rekurze využívá ;) To uvidíte v dalším článku při implementaci. Dobrý programátor, který spravuje např. web o několika desítkách nebo dokonce stovkách tisících stran s několika tisíci požadavky denně(např. rozsáhlý elektronický obchod či fulltextový vyhledávač), musí spoléhat právě na co nejefektivnější algoritmy. Vymýšlení rychlejších a úspornějších algoritmů je dnes priorita v mnoha oborech a kdo to nazývá "kontraproduktivní", ten s prominutím nic o skutečném programování neví ;)
Datum vložení: 24.7.2005 11:05:39
Spíš jste si asi nečetl můj příspěvek:) Mluvil jsem o velmi jednoduché rekurzi, vaši za velmi jednoduchou nepovažuju. >> ...např. rozsáhlý elektronický obchod či fulltextový vyhledávač... Tyto systémy by právě měly mít velmi vymakanou keš. K rychlosti kódu... Snažší & rychlejší mi přijde uložit si u každého názoru ID článku a ID mateřského příspěvku. Pak stačí načíst do polí všechny názory dle ID článku a s nima pracovat. Za kontraproduktivní považuju psaní kódu, který je časově náročnější k napsání a neposkytuje žádné výrazné výhody. (bude srovnatelně rychlý, jako ten, který popisuju v odstavci výše)
Datum vložení: 24.7.2005 13:51:14
[i]Snažší & rychlejší mi přijde uložit si u každého názoru ID článku a ID mateřského příspěvku. Pak stačí načíst do polí všechny názory dle ID článku a s nima pracovat.[/i] To už předbíháte k praktické implementaci. Ano, samozřejmě přesně tak příspěvky budou v databázi [i]Za kontraproduktivní považuju psaní kódu, který je časově náročnější k napsání a neposkytuje žádné výrazné výhody[/i] Kdo ovládá "teorickou" informatiku, tomu vymyšlení tohoto efektivního algoritmu zabere pár minut ;)
Datum vložení: 25.7.2005 23:02:30
Nezbývá než popřát štěstí s dalšímy články, které si rád přečtu:).
Datum vložení: 22.7.2005 12:48:57
Nechápu, proč se strom řeší vždycky takhle složitě přes indexy. Znám řešení, u kterého stačí k vypsání (seřazeného!) stromu pouze 1 dotaz do databáze, jeho použití je jednoduché, efektivní, intuitivní... Viz http://forum.kyblsoft.cz/oforu v odstavci "Jak jsou udělána vkládání...". Sám jsem to na uvedené adrese (a na dalším serveru) naimplementoval, a nemůžu si stěžovat :-)
Datum vložení: 22.7.2005 13:04:37
Celkem dobré a efektivní řešení, ale jak ukládáš ten kód typu 1001003? Protože při hodně hluboko vnořené debatě narazit na maximální délku položky nastavenou v databázi.
Datum vložení: 22.7.2005 13:13:37
Mám tam omezení na 10 vnořených odpovědí (jde jen o to, jak dlouhý chci mít ten řetězec), poté se automaticky odpovídá na 9. příspěvek. V tomto zanoření ale stejně většinou diskuse připomíná chat, kde se dohadují jen dva - navíc by byly odpovědi "příliš moc vpravo". Jeden kámoš tenhle přístup obšlehl ode mě a má max. 70 vnořených odpovědí - proč ne ;-)
Datum vložení: 22.7.2005 14:14:32
Zaujímavé riešenie, ale zbytočná redundancia dát v databáze. Pokiaľ ide len o vypisovanie celej štruktúry všetkých komentárov tak sa to dá aj jednoduchšie. Taktiež jedným selectom v databáze. Už som to tu dvakrát spomínal a zdá sa mi to teda o dosť jednoduchšie a efektívnejšie ako to tvoje riešenie. Ak má to tvoje nejaké výhody, ktoré nevidím tak sem s nimi.
Datum vložení: 22.7.2005 14:23:17
Koukal jsem na to, ale nějak nevidím rozdíl mezi tvým řešením a tím mým :-)
Datum vložení: 22.7.2005 14:25:07
Sorry, už jsem na to asi přišel, ale jak bys to chtěl vypsat jedním selectem? To je stejná rekurze jako všude jinde (?).
Datum vložení: 22.7.2005 14:44:48
Rekurzia absolútne nie je problém. Tá sa používa len na vypisovanie. Úzke hrdlo je len keby si chcel v rekurzii nejako naťahovať postupne tie uzly stromu. To by bolo veľa selectov a to je problém. Ono to funguje takto. Jeden select natiahne a usporiada komentáre - čo ja viem napríklad podľa dátumu. Potom na to pole poženieš ten môj algoritmus, ktorý z toho spraví pole, ktoré je vlastne reprezentácia toho stromu. Ten algoritmus je lineárnej zložitosti čiže vcelku efektívny. Ten už pracuje z poľom v PHP a nerobí žiadne selecty alebo náročné operácie. No a potom už máš pekné pole, ktoré sa dá krásne vypisovať. Rekurzívne, zásobníkom či akokoľvek. Fakt neviem kde vidíš problém.
Datum vložení: 22.7.2005 18:43:17
A kolik myslíte, že potřebujete SELECTů v mém algoritmu, samozřejmě taky jeden, vše ostatni by byla chyba...
Datum vložení: 23.7.2005 17:48:48
chyba? to je zajimave tvrzeni se kterym bych si dovolil rovnou nesouhlasit... a ted k prisevku na nez reagujete i vy, pokudsem to pochopil tak ten retezec 10001001001 bude patrne nejaky hezky string, coz je pro indexaci db ne vzdy dobre, navic mate omezenou pocet odpovedi na 10, osobne si myslim ze rekurzivni reseni i s vice dotazy kde se indexuje podle cisla muze byt rychlejsi. navicmoje zkusenost s diskusemi je takova ze je vzdy malo vetveni a pak najednou prispevek ktery vyvola vasne a u nej sou debaty rozsahle...
Datum vložení: 24.7.2005 0:46:04
[i]chyba? to je zajimave tvrzeni se kterym bych si dovolil rovnou nesouhlasit...[/i] Můžete to prosím rozvést? Na pouhé vypsání diskuse pod články používat několik desítek až stovek dotazů na databazi není imho dobré řešení ;) Pokud ale máte příklad, kde to efektivní je, myslím si, že by to tuto diskusi jistě obohatilo ;)
Datum vložení: 24.7.2005 10:24:29
takze autor prvni diskusni prispevku pise ze pouziva index jako nejaky string 1000100101 a ja rikam ze podle me muze byt v klidu forum ktere se vypisuje rekurzine s ciselnym index a vice selecty rychlejsi... na rekurzivnim vypisovani s vice selecty nevidim nic spatneho... indexovani 100 prispevku kdy hlavni prispevky mimo strom se daji ziskat jednim selectem a zbytek rekurzi je pri indexaci cislem pro db system podle me hracka. vase reseni mi asi trochu uniklo matici nasledniku znam z teoreticke informatiky jako pojem ale tady ji tvorite kdy pri kazdem vypisu? nebo si ji nekam ukladate? uz se tesim na implementaci ztoho to snad pochopim i ja:)
Datum vložení: 22.7.2005 13:13:18
[i]Stromové zobrazení diskuse sebou ale přináší spoustu problémů. Obvykle totiž známe u každého příspěvku pouze jeho číslo (index) a číslo toho, který mu předcházel. Přitom pro výstup bychom potřebovali dvě pole - v jednom budou uloženy čísla příspěvků tak, jak za sebou půjdou ve stromu, a ve druhém bude informace, o kolik je každý příspěvek ve stromu odsazen.[/i] Nerozumím, proč pokud někdo potřebuje ukládat úroveň vnoření, tak proč ten údaj přímo do databáze také neukládá? Jinak musím říct, že se mi ten článek zdá šíleně překomplikovaný. Stačí prostě to fórum rekurzivně zpracovat a je to. A ještě jedna poznámka, často je potřeba nějaký příspěvek z debaty vymazat (respektive ho označit tak, aby se nezobrazoval). Tady je nutné počítat s tím, že na takový příspěvek už také můžou být samostatná vlákna s reakcemi a je tedy nutné si zvolit, zda je také zrušíme nebo budeme zobrazovat nějak jinak.
Datum vložení: 22.7.2005 18:33:37
Poku se příspěvek z debaty "vymaže", jednoduše se jeho následníci nezobrazí. To je jen maličkost a z vygenerovaných dat to může zajistit klidně třeba až XSLT ;-)
Datum vložení: 23.7.2005 18:28:37
[i]Jinak musím říct, že se mi ten článek zdá šíleně překomplikovaný. Stačí prostě to fórum rekurzivně zpracovat a je to.[/i] Pokud jste programátor, připadne Vám možná rekurze jednoduchá, ale nevěřím, že každý kdo dnes v PHP dělá, principy byť jen obyčejné rekurze zná ;) Článek se snažil to vysvětlit podrobně. Ukazuje, jakých algoritmů se zde využívá a co se vlastně během algoritmu děje. To, že je strukturovaných diskusí na internetu málo, jenom ukazuje, že problém diskusí asi není nejjednodušší na vyřešení ;)
Datum vložení: 24.7.2005 13:51:57
Jabych lidi co pisi v PHP neodsuzoval mam radsi javu ovsem nemyslim si ze programator v PHP = negramotny programator(kazdy podle me casem zjisti ze Java nabizi vic nez PHP :)))). Jinak podle meho soukromeho nazoru je rekurze naprosty programatorsky zaklad a kazdy kdo programuje prosel jistou algoritmickou prupravou kde se rekurze hojne vyuziva ;).
Datum vložení: 24.7.2005 14:01:08
Já jsem nikde neuvedl, že "programator v PHP = negramotny programator", já jen říkám, že ne každý "programator" ovlada i teorii algoritmu. Sám jsem se setkal s větším množstvím programátorů, kteří to neumí než s těmi, kteří skutečně programovat umí ;) Jinak ještě poznámku k Vašemu srovnání PHP a Javy - jsou to dva odlišné jazyky, proto bych je rozhodně nesrovnával ;)
Datum vložení: 24.7.2005 21:05:22
Osobne cloveka co neumi rekurzi nepovazuji za programatora :), pokud nekdo pise jednoduche weby v PHP tak patrne nevyzije ani vasi konstrukci, ja sem negramotnost samozrejme pouzil v nadsazce. Java(v prostredi netu) i PHP se vyuzivaji na totez a tudiz se to dle meho nazoru srovnat da - ale to sempsal jen v zertu a protoze mam javu opravdu rad :).
Datum vložení: 23.7.2005 20:41:02
Jiste ze existuje kratsi popis - ze vstupniho pole vytvorime pole nasledniku a to rekurentne prochazime do hloubky, cimz vzdy jiste ziskame veskere nasledniky prvku, z nejz rekurzi spustime. A to je vlastne vse. Nechci se nikoho dotknout, ale pokud by rozumel tomuto popisu (a ve vetsine pokrocilych ucebnic programovani se hlubsich nedockate), tak si ten algoritmus navrhne sam. Pokud to nedokaze, pak je zjevne zacatecnik a v tom pripade si nemyslim, ze je dobre uvadet jen kucharku. Prinosnejsi je podle me uvest zpusob, jakym se algoritmus navrhuje, aby uz od zacatku byly pestovany spravne navyky, presne tak, jak je to podrobne uvedeno v tomto clanku.
Datum vložení: 22.7.2005 14:33:54
Ja uprednostnujem jednoduche riesenie bez stromu. Teda len prispevky nad sebou, kde kazdy prispevok ma svoje cislo a ked niekto chce reagovat, tak ho oslovi podla toho poradoveho cisla. A basta.
Datum vložení: 25.7.2005 1:55:37
A můžete mi uvést jediný důvod proč to upřednostňujete? Já tedy upřednostňuji stromové zobrazení z důvodu přehlednosti. Nevím, možná máte rád větší chaos. ;)
Datum vložení: 25.7.2005 10:07:45
U diskuse pod články také upřednostňuji prostý neodsazený seznam s odkazy na co kdo reaguje, protože v běžné diskusi to odsazování je spíš nepřehledné než užitečné. Jiná věc jsou ovšem různá odborné diskuse a znalostní báze, tam může být odsazování užitečné. Ovšem v každém případě by takový strom měl mít možnost "sbalit" větev která mě nezajímá a další ovládací prvky (sbalit vše, rozbalit vše, rozbalit celé vlákno). To je ovšem Javascript takže to většina programátorů k naší škodě ignoruje.
Datum vložení: 22.7.2005 16:54:43
pro potreby ulozeni hierarchicky strukturovanejch dat do databaze se da s uspechem pouzit nasledujici metoda: http://www.sitepoint.com/print/hierarchical-data-database jednoduchy a elegantni.
Datum vložení: 22.7.2005 18:32:18
Ještě lépe a v češtině viz http://interval.cz/clanek.asp?article=3801 ;-)
Datum vložení: 16.8.2005 18:17:35
http://www.builder.cz/art/php/disccuss_sql.html
Datum vložení: 29.12.2006 19:31:29
Prosim vas nemohli by jste mi na e-mail poslat diskusi treba ve formatu rar ja na to nemam cas. Dekuji
Datum vložení: 15.2.2008 22:05:24
Chceš si lehce vidělat? .. zkus to na http://cz.iq-test.eu/?d=7074 ..a ještě u toho zjistít jaký IQ máš :-)
Datum vložení: 11.6.2008 7:50:45
Lucka Vondrackova vydala nove 2 CD Pisnicky jsou k poslechnuti na fanwebu Lucky: http://fanklub.lucievondrackova.cz . Na CD je 17 nových písniček a 7 remixů. S.Č.