kruta fiška. paldies.

Ļ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 :)

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.

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?

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!

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!

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.

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.

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.

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).

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

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.

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