Návrh pre abclinuxu.cz

31.10.2006 11:08 | Přečteno: 2420×

Malý návrh pre tvorcov tohoto servera (Java bŕŕ, tak aspoň takto)

Príspevky

Jedna tabuľka pre všetky príspevky:

Entry
 - id, int4, autoincrement, primary key)
 - parent, reference Entry, default null
 - type, reference EntryType,
 - account, reference Uzivatel, default null
 - anonym, text, default null
 - time_insert, time,
 - time_modify, time,
 - time_deploy, time, default null,
 - status, reference EntryStatus
 - subject, text, default null
 - uvod, text, default null
 - content, text, default null

parent ... nadradený príspevok, null pre root Entry

Tabuľka stromu:

EntryTree
 - id
 - ancestor, reference Entry
 - descendant, reference Entry
 - depth, int

index (ancestor)
index (descendant)

vytvorenie nového Entry

entry = new Entry;
"insert into entry_tree (ancestor, descendant, depth)
   select select ancestor, entry.id, depth + 1
   from entry_tree
   where descendant = entry.parent
"
"insert into entry_tree (ancestor, descendant, depth)
    values (entry.id, entry.id, 0)
"

Vysvetlenie:
EntryTree sleduje všetky cesty v strome (a ich dĺžku), ak ich budeme považovať za jednosmerné.
Príklady:
celý podstrom zadaného rootid:

select A.descendant parent, B.descendant child
  from tree_node_path A, tree_node_path B
 where A.ancestor = rootid
   and A.descendant = B.ancestor
   and B.depth = 1
 order by parent, child

pri predpoklade, že Entry.id je trvale rastúce, môžeme strom budovať:

map[rootid] = new Entry (rootid);
while ((parent, child) = fetch_row) {
  map[parent].add_child (child);
  map[child] = new Entry (child);
}

map je asociatívne pole

výber cesty po leafid:

select ancestor
  from entry_tree
 where descendant = leafid
 order by depth asc

Entry je každý príspevok (článok, správička, blog, komentár, ako i napr "sekcia hardware" alebo "sekcia "Software/alternatívy").
Výhody:
užívateľ si môže nastaviť sledovanie ľubovoľného stromu (napr i časti diskusie).

Entry::Status
enumerácia s hodnotami NEW, ENABLED, LOCKED, DELETED

Entry::Type
typ príspevku, enumerácia napr: ARTICLE, NEWS, COMMENT, BLOG, CATEGORY, POLL

Sledovanie

AccountWatch
 - id
 - account, reference Account (uzivatel)
 - entry, reference Entry

Výber prihlásených pri vložení príspevku (resp pri jeho publikovaní):

entry = new Entry;

select account
  from account_watch, entry_tree
 where account.entry = entry_tree.ancestor
   and entry_tree.descendant = entry.id

Posielanie mailov

Navrhoval by som vypĺňať hlavičku In-Reply-To a Message-ID. In-Reply-To podľa entry.parent (ak nie je null), Message-ID podľa entry.id. Postačovať by mal tvar 1234watch@abclinuxu.cz

V prípade záujmu môžem pokračovať návrhom systému hodnotenia príspevkov.        

Komentáře

[Filip Jirsák]

Možná jsem nepochopil ten fígl, ale Abíčko data do databáze ukládá ve stromové struktuře – tj. jsou jednotlivé entity a ty mají mezi sebou vztahy rodič – potomci. Viz stránku se zdrojáky, kde je odkaz na články o datové struktuře i samotný SQL dump.

[happy barney]

ak máte na mysli stĺpec data, je to niečo magické, nad ktorými sa potom nedajú robiť databázové operácie, nedá sa na ne odkazovať, ich update znamená cyklus decode-encode.
Zdrojáky som si samozrejme prešiel, preto som tento návrh napísal.

[Filip Jirsák]

V odkazovaných článcích Leoš popisoval, proč se rozhodl použít zrovna tenhle způsob. Je to taková simulace skoro-XML databáze nad relační databází. Pokud by se s tím mělo hýbat, tak jsou asi jen dvě možnosti: opravdová XML databáze (a je otázka, zda dnes existuje taková, které by bylo možné svěřit data Abíčka), nebo klasická relační databáze, kde bude jedna tabulka pro články, jedna pro komentáře atd. Nevidím žádný přínos toho rozšiřovat tabulku Entry o sloupce, které se někdy použijí a jindy ne a jindy stejně nebudou stačit…

Nechci odmítat cokoliv jiného (ostatně já jsem tu databázi nenavrhoval a databáze navrhuji jiným stylem), ale nevidím mezi vaším návrhem a současným stavem prakticky žádný rozdíl.

[happy barney]

zjednotenie všetkých typov do jednej tabuľky umožňuje použiť na každý typ rovnaké operácie, napríklad hodnotenie, komentovanie, sledovanie (napr sledovanie časti diskusie, alebo časti diskusie). Pri pridaní nového typu, tento zdedí túto funkcionalitu. To by zabezpečila tabuľka

EntryWatch
 - id
 - account
 - entry

Rozšírenie tabuľky Entry o null-able stĺpce je z dôvodu spätného selectu, napr. pri funkcii "čo sa napísalo v označených/navštívených Entry, odkedy som tu nebol", tabuľky EntryMark, EntrySeen (rovnaké ako EntryWatch).

Rozdiel je jednoznačný, súčastný stav funguje

[Filip Jirsák]

Aha Takže to celé by umožnilo označovat zprávičky, články, zápisy v blogu a záznamy v HW a SW od mé poslední návštěvy? To mi dělá RSS

[happy barney]

nielen, platí to pre ľubovoľný Entry.
Rozdiel je v jednom: ak by malo existovať ekvivalentné RSS, muselo by existovať pre každé Entry.

[Josef Kufner]

Stromy je výhodnější vylepšit o sloupce left a right. Které budou obsahovat taková podivná čísílka. Pak totiž stačí na vykreslení celého stromu jeden jediný select. Také sečtení přečtených nepřečtených příspěvků na titulní stránce je pak o jednom joinu a group by. A aby nebyly ztráty výkonu při přidávání příspěvků tak velké, stačí mít ještě u každého uloženo id stromu (diskuze), takže update běží jen na relativně malém množství záznamů.

[Josef Kufner]

A pokud to chce někdo vidět hotové, tak tohle to používá.

[happy barney]

left-right má dosť vysokú réžiu na rebuild stromu pri pridaní, ktorá zároveň musí byť atomická.

[Josef Kufner]

Ve srovnání s rekurzivním procházením stromu při každém zobrazení to i tak vyjde výrazně lépe.

[trekker.dk]

Proč Atlantis ?

[Josef Kufner]

Mě se neptej, tuhle část názvu jsem převzal.

[Pavel 'lingeek' Szalbot]

Psal jsem tu o tom článek...

[Josef Kufner]

A nechceš napsat ještě nějaký? Tohle se děsně blbě hledá...

[Robert Krátký]

Stromy v SQL

Hint: kliknout na jméno autora komentáře a pak na "Seznam příspěvků na abclinuxu.cz"

[Josef Kufner]

O tom jednom vím (došel jsem k němu včera tou cestou co píšeš), právě proto říkám, že by byl fajn ještě nějaký další.

Teda, že mi někdo z redakce bude rozmlouvat výzvu k napsání článku, jsem fakt nečekal

[Leoš Literák]

Diky za snahu, ale na zasadni zmeny backendu je pozde asi tak o 6 let.

Rekurzivni monitory mam v planu, jsou i v bugzille a pujdou udelat relativne snadno i v soucasnem modelu. Akorat mi jeste neni jasne, jak bych udelal sledovani vlaken v diskusi, nicmene sledovani na urovni celych objektu bude snadne.

Jenze nasledne bude vhodne udelat i dalsi zpusoby informovani o novych udalostech. Ted kdyz si date sledovat nejaky flamewar, muzete za hodinu dostat desitky emailu. Pri rekurzivni sledovani muzete dostavat stovky mailu za den. Proto je treba napsat alternativy k InstantSender, napriklad BatchSender (poslat souhrnny email jednou za den) nebo InternalMessageBox (ukladani zprav do abicka, neco jako Mate 4 nove zpravy, dalo by se zobecnit i pro posilani zprav mezi uzivateli, kteri nemaji platnou emailovou adresu).

[happy barney]

hmm, abc instant message ?
Nebude jednoduchšie import/export cez jabeer, nntp ?

čo sa týka emailov a flame ... podľa mňa stačí správne vypĺňať hlavičku, aby sa správy zgrupovali. V mailing listoch sa bežne stáva veľa mailov za den.

[Leoš Literák]

Pokud vim, tak hlavicku vyplnujeme spravne a vlakna v pohode funguji. Nicmene na kazdemu se libi, kdyz mu dorazi behem kratke doby par desitek emailu a s tim podpora vlaken nema zadnou souvislost NNTP podporujeme uz davno pres gmane.org, viz stranka diskusniho fora. XMPP nekdo zadal, muze to byt dalsi alternativni implementace InstantSenderu. AbcInstant message nebude, mel jsem na mysli jen schranku se vzkazy, nekdo to po mne z adminu nedavno chtel, ze by to preferoval misto emailu.

[Josef Kufner]

Tak ať si ten někdo pořídí ke své schránce webmail