1 lasītājs @ 22:20 (2004. gada 26. oktobris)

kruta fiška. paldies.

2 japets @ 22:33 (2004. gada 26. oktobris)

Ļoti interesanti, bet, manuprāt, šāda struktūra der tikai specifiskos gadījumos vai arī es vienkārši necērtu un uz sitiena nespēju izdomāt gana labus algoritmus šādām darbībām:
1. samainīt vietām viena parenta divus childus
2. ar viņu uzsvērto "vienu selektu" izselektēt kāda zara childus, visus parentus un parentu brāļus (un māsas :)

3 bubu @ 22:47 (2004. gada 26. oktobris)

Var var, japets, ar šo to izdarīt. Uz sitiena neatceros, bet webā ir viens pdf dokuments. Graph algorithms in SQL (vai kautkā līdzīgi) kur šitā struktūra sīki sīki izanalizēta un izskaidrotas visādas operācijas un darbības ar to.

4 japets @ 23:13 (2004. gada 26. oktobris)

par to ka var izdarīt es nestrīdos, bet vai rezultātā nesanāk gana liela ateja (ja tā drīkst nosaukt nepārāk populāru algoritmu izmantošanu :)?
Ta jau labāk, kā līdz šim — glabāju koku atmiņā un pie izmaiņām pārlādēju (vai arī pamainu atmiņā pa tiešo). Vienīgi šis variants laikam pagaidām tā īsti nav realizējams iekš php?…
enīvei, ja kāds zin linkuci uz bubu pieminēto pdf, viņš droši drīkstētu padalīties, jo esmu gana slinks, lai nemeklētu lietas, kas nav aktuālas.. :)

P.S. vai tas ir normāli, ka šis textarea rakstīšanas laikā scrollojas uz pašu augšu?

5 Livingston @ 09:05 (2004. gada 27. oktobris)

Palasiet arī nākamo lapu tajā adresītē, kur kautrīgi ir pieminēti arī trūkumi. Galvenā problēma ir ar hierarhijas papildināšanu, jo ielikt jaunu nodi ir ļoti dārgi. Lielākā daudzlietotāju sistēmā būtu REĀLAS problēmas, jo darbības bieži vien bloķētos!

6 Elmaris @ 10:35 (2004. gada 27. oktobris)

Man nepatīk… Binārie koki sūkā.. Ko darīt, ja nu man pēkšņi sagribas blakus augļiem un gaļai arī dārzeņus ieglabāt?

Bet specifiskajiem (binārajiem) gadījumiem, man liekas, šī ir diezgan kruta fiška!

7 japets @ 10:50 (2004. gada 27. oktobris)

Elmaris, manupraat tur nav mineets, ka tas der tikai binaarajiem kokiem. Tiesa, piemeers gan ir binaaram kokam, kas arii mani saakumaa samulsinaaja :). Nesaskatu kaadas iipashas probleemas, kas nebuutu binaarajiem, bet buutu vienkaarsham kokam shaadaa struktuuraa.

8 Mayer @ 11:43 (2004. gada 27. oktobris)

Nav slikti, bet kā jau citi teica ir problēmas ar jaunu radīšanu (to gan var appiet, iesākumā zinot aptuveno koka dziļumu, kā arī bērnu skaitu/pieaugumu konkrētā koka līmenī). Taču situācijā, kad man vajag viena tēva bērnus vinu/divus līmeņus uz leju, sākas problēmas.

9 Peeteriz @ 12:13 (2004. gada 27. oktobris)

Sorry, bet šajam gadījumam ir nereāli dārga insertošana… Ja ir visi dati jāapdeito, tad tas nav normāli.
Principā ar defaulto koku realizāciju var ļoti normāli iztikt (vienk links uz augšu), vai arī ar indeksu stringa veidā — piem glabāt 'Food.Fruit.Banana', un tad ar indeksiem var normāli (ātri) dabūt visus, kas ir zem Food.Fruit, piemēram.

10 laacz @ 12:17 (2004. gada 27. oktobris)

Vispār, parasti (lielākajā vairumā gadījumu) datu ievietošana notiek neskaitāmas reizes retāk, nekā datu atlasīšana. Attiecīgi, starpības nav, vai izmanto svērto b–tree left right metodi, kur datu ievietošana notiek grūtāk, vai arī pierasto metoid, kur smagākais ir selekts (vai arī vienu reizi keša izveidošana).

11 Livingston @ 12:30 (2004. gada 27. oktobris)

Viss tiešām atkarīgs no pašas sistēmas arhitektūras un prasībām, bet par ļoti "scalable" šo risinājumu nenosauksi :)

12 ulzha @ 13:31 (2004. gada 27. oktobris)

Kopš kura laika "defaultā koku realizācija" ir "vienk links uz augšu"? Mans gan teiktu first_child un next_sibling, un, ja ļoti vajag, tad uz augšu arī. Vienalga, nopietniem risinājumiem ir speciālas datubāzes. Laacz — b–tree != binary tree. Japets — PDFus gudrus un dumjus var atrast iekš citeseer.

13 cyberspace @ 23:50 (2004. gada 28. oktobris)

Buju kaadu ilgaaku laicinnu atpakall ar to saskaaries, neko isti sliktu nevar teik, tikai to, ka ir lloti ruupigi jaaseko lai lft un rght butu pareizi, jo dzessot vai paarnesot datus no vienas vietas uz citu mainas taa seciba un ir jaapaskaita visu koku:D