datu strukturizācija portālveidīgajam

[hmnc]

Sveiki!

ir viens tāds mānīgs jautājums. vienvārdsakot ir divas tabulas:

viena tabula, kas veido portāla struktūru (piemēram ziņas -> novadu ziņas -> ventspils -> ... ), kas balstīta uz parent-child.

otra tabula veido saturu, kas attiecīgi sastāv no raksta zem noteiktas GALA ( - pēdējās sadaļas attiecīgajā zarā) sadaļas. nu respektīvi, ja pēdējā sadaļa struktūrā "ziņas->novaduziņas" ir "ventspils", tad rakstus var bāzt apakšā tikai zem "ventspils", bet NEvar zem "novadu ziņām" un vienkārši "ziņām".

 

problēma sekojoša - nevaru izdomāt, kā pareizi sasaistīt rakstus ar struktūru tā lai atverot "novadu ziņas" parādās gan "ventspils", gan "liepāja", gan "rēzekne", utt. respektīvi atverot jebkuru struktūras sadaļu izbirtu ārā visi child elementi visām child apakšstruktūrām.

 

esmu izdomājis divus variantus, bet neviens no tiem man īsti labi nesimpatizē:

1. pie rakstu tabulas piebāzt klāt vēl pāris lauciņus ar sub1, sub2, sub3, kuros attiecīgi ierakstīt zem kurām sadaļām raksts būtu pabāžams. mīnuss šim visam pasākumam ir maksimāls nedinamiskums (ja gribēs pielikt klāt 20 apakšsadaļas tad būs jāveido 20 sub* lauciņi)

2. atverot vaļā kādu sadaļu, tiek izvilkti visi apakšstruktūru child ID un tiek veikts selects pēc visiem tiem ID. labums tāds, ka satura tabulā būs tikai viens lauciņš, kurš norādīs uz sadaļu. sliktums tāds, ka atverot kādu sadaļu, tur var būt uz 30-40 child elementu, un taisīt šādu selectu nebūtu prātīgi.

 

varbūt ir vēl kāds veids, ko nevaru rīta agrumā izdomā :)

principā ideja tāda pati kā tvnet/apollo, u.c. portāliem - kā viņiem tur tas viss tiek strukturizēts?

 

ceru, ka uzrakstīju daudz maz skaidri :)

 

paldies par atbildēm jau iepriekš.

[bubu]

Šāda koka struktūra nav laba tavam uzdevumam. Vai nu jāņem tas 2. punkta risinājums, vai jādomā savādāka struktūra (1. gan nav labs variants, manuprāt).

[v3rb0]

pirmais nebūs īsti labs.

 

ziņu lapai ziņas nemainas reizi secundē tāpēc es ņemtu kaut ko kā otrais variants un domātu par kešošanu.

[hmnc]

bubu - hmm.. kādā ziņā koka struktūra nav laba priekš šī uzdevuma? kā tad piemēram ir ar tvnet? viņiem ir praktiski tāda pati struktūra, kādu vēlos panākt es :)

 

v3rb0 - mmmm... par kešošanu biju piemirsis. bet nu tas ir tikai veids kā to visu padarīt serverim draudzīgāku. pamata struktūra ta vienalga jāveido ir :)

[bubu]

Kā tu zini, kāda viņiem db struktūra?

[hmnc]

neinu db struktūru jau nezinu, tāpēc jautāju :) viņiem ir visa tā pati struktūras fiška ir tāda kādu es gribētu, bet kā dati un sadaļas viņiem ir strukturizētas - hvz

[Delfins]

select N.* FROM news N
where N.catid IN ( select catid from categories_getallchildren($currentCatId) )

 

piemērs funkcijai

CREATE OR REPLACE FUNCTION inventgroups_getallchildren(inventgroupid int8)
 RETURNS SETOF itemgrouprelationnode AS
$BODY$declare
   R	  itemgrouprelationnode;
   SR	 RECORD;
begin
 FOR R IN select ItemGroupId, ParentItemGroupId
		  from InventGroups where ParentItemGroupId = $1 AND ItemGroupId != $1
 LOOP
	 RETURN NEXT R;
	 FOR SR IN select * from inventgroups_getallchildren( R.ItemGroupId )
	 LOOP
		 RETURN NEXT SR;
	 END LOOP;
 END LOOP;
 RETURN;
end;$BODY$
 LANGUAGE 'plpgsql' VOLATILE;

 

 

PS: izmanto PGSQL un nečakarējies ar visādiem sūda mysql...

Edited February 26, 2006 by Delfins

[bubu]

MySQL nav sūda mysql. Tikpat labi ir lietas, kur pgsql ir sūda.

Katrai lietai savs pielietojuma lauciņš.

[hmnc]

hmm.. PGSQL? principā gribētu iekļauties savās zināšanu robežās, jo apgūt jaunas tehnoloģijas prasa laiku.

bet nu ja pgmysql būs krietni pārāks par mysql tad padomāšu.

 

bubu - tev varbūt ir kādi detalizētāki varianti? :)

[bubu]

wtf ir pgmysql?

 

Stulbs, bet laikam vienkārš variants. Jauna starptabula (raksta_id, kategorijas_id), kur salikt visus linkus no raksta uz visām sadaļām, kurās vajadzīgs to parādīt. Tik baisie updeiti un čekošana būs vajadzīgi, ja mainīsies kategoriju izkārtojums kokā.

[Delfins]

Es par to arī saku, ir lietas, kas jau izgudrotas un tās var pielietot dzīvē.

Tas ka pieturēties, MYSQL for WEB, un principu pēc palikt pie mysql, nu nez - vai ir jēga... Postgre vairāk der portālam, jo tam fīču vairāk - Views, StoredProc, savi tipi, handleri, savs cast-mehānisms, sequences,.. būtība viss kas ir standarta RDBMS... Es nenoliedzu, ka tas viss Mysql daļēji ir.. bet dzirdēts, ka tas viss gļuko un bremzē, un nav `tā īsti kā parasti`..

 

Tāpēc rodās jautājumi, kā šito un to, raksta baigās cache-sistēmas, overloado sql-serveri..

 

Bet ir jau gatavs lietas, kur tas viss izzi-pizzi minūtes laikā uzkodējams, tāpēc es jau iesaku pēc pieredzes, bet nu katram pašam jāizvēlās savs ceļš ejams :)

[hmnc]

tfu bļin par to pgmysql nogļukoju :D aizdomājos par kko.

 

hmmm... starptabula izklausās nāvējoši. tiesa gan kategoriju izkārtojums kokā nemainīsies. hmmm.. īstenībā ja tā padomā, tad katrs raksts tiks iemests starptabulā max 2-4 reizes (atkarībā no koka dziļuma)... padomāšu par šādu variantu

 

Delfins - hmmmmm.... tu liec man aizdomāties :)

principā uz servera nav nekādu ierobežojumu tāpēc var derēt praktiski dajebkādi risinājumi. tik es baidos no tā, ka tas aizņems daudz vairāk laika nekā taisot uz mysql, jo pgsql man pavisam sveša tehnoloģija.. neinu sql jau tas pats, bet visas tās advanced features..

[Delfins]

plpgsql ~= oracle plsql (ja tas ko līdz)

 

Ar storētām proc un view-iem būs tā, ka daļa koda būs uz DB, kura nav jārakasta 1000x reizes kodā

 

PS: vajadzēja studēt, vai ar pašapmācību nodarboties. Ar zināšanām tā ir kā ir - nedrīkst atpalikt...

[v3rb0]

par trūkumiem mysql5 storētas procedurās/f-jās/trigeros piekrītu - nav nekas megalabs pagaidām vēl tur - pamati ir, bet tas ar arī viss.

[Delfins]

tāpēc kā engine neļauj bŗivi izpausties... ora/pg/ms jau tas bija pamatos (PG gadījumā engins tika pārrakstīts kaut kādā tur versijā)