Как, в чём хранить связи между данными ? Ведь количество связей

← →
Кен © (2004-02-22 05:00) [0]

может быть больше чем самих данных, поэтому их удобное хранение и быстрая обработка крайне важны.
Речь идёт не об обычном дереве ! Каждая единица данных должна иметь много Parentов и много Childов. Как удобнее организовать хранение всего этого добра ?

← →
Кен © (2004-02-22 05:06) [1]

Максимальное количество возможных связей для N элементов будет равно :

(N^2 - N)/2

Поправьте если ошибаюсь.
То есть уже при 10 000 элементах связей будет 49 995 000. А уже при 100 000 привысит разумные пределы.

← →
Alex Konshin © (2004-02-22 06:00) [2]

Списки детей и, возможно, родителей.

← →
Кен © (2004-02-22 06:24) [3]

> Alex Konshin © (22.02.04 06:00) [2]
> Списки детей и, возможно, родителей.

Размерность списков ? 50 мегабайт под них резервировать ?

Как грамотно удалить элемент со всеми его Childами ? Ведь если этот Child является ещё чьим то Childом, то удалять его нельзя. Плюс надо недопускать зацикленности, когда скажем A является чайлдом Б, Б является чайлдом С, а С является чайлдом А.

← →
Alex Konshin © (2004-02-22 07:09) [4]

Что значит "размерность списков"? Что такое список понимаешь?

Если хочешь, могу порекомендовать мой юнит ChainPools (возможно, что я и пожалею об этом). Он, по сути, является быстрым менеджером памяти, расчитанным на выделение кусочков памяти одинакового размера. Он написан так, что не вызывает фрагментирование памяти.
В твоем случае его можно использовать для хранения списков детей и родителей.

С ним это будет выглядеть как-то так:

- Пусть твой класс будет TMyItem.

- В класс TMyItem введи поле-якорь списка детей и, если нужно, родителей:
FChildren : PChainLink;
FParents : PChainLink;

- Поле FValue из TChainLink используй для хранения адресов объектов TMyItem.

- В самом начале создай пул цепочек:
oChainPool : TChainPool;

oChainPool := TChainPool.Create(SizeOf(TChainLink));

- Чтобы добавить какой-то обект obj:TMyItem в список детей другого объекта obj2, используй
oChainPool.AddValue( LongInt(obj), obj2.FChildren );
либо PutValue.

- Обработку цепочки можно организовать с помощью функций ScanChain или врукопашную, это не сложно:
pItem : PChainLink; pItem := obj.FChildren; while pItem<>nil do begin with TMyItem(pItem.FValue) do begin // do something end; pItem := pItem^.FNext; end;

← →
Кен © (2004-02-22 07:16) [5]

> Alex Konshin © (22.02.04 07:09) [4]
> Если хочешь, могу порекомендовать мой юнит ChainPools (возможно,
> что я и пожалею об этом). Он, по сути, является быстрым
> менеджером памяти, расчитанным на выделение кусочков памяти
> одинакового размера.

Так размер то у всех разный. У одного элемента один родитель и один чайлд, а у другого тысяча родителей и ещё больше детей.

← →
Alex Konshin © (2004-02-22 07:16) [6]

Ну а это
Как грамотно удалить элемент со всеми его Childами ? Ведь если этот Child является ещё чьим то Childом, то удалять его нельзя. Плюс надо недопускать зацикленности, когда скажем A является чайлдом Б, Б является чайлдом С, а С является чайлдом А.
задача для студента первого курса, сам разберешься.

← →
Alex Konshin © (2004-02-22 07:18) [7]

Так размер то у всех разный. У одного элемента один родитель и один чайлд, а у другого тысяча родителей и ещё больше детей.
О господи, и кто меня за язык тянул...
Каждый кусочек для одной связи. Это всего 8 байт на связь.

← →
Alex Konshin © (2004-02-22 07:20) [8]

Кстати, это не ты ли интересовался реализацией хеша? Я там тебе ответил.

← →
Кен © (2004-02-22 07:25) [9]

> Alex Konshin © (22.02.04 07:16) [6]
> задача для студента первого курса.

Сказал "гоп" и не перепрыгнул.

> Alex Konshin © (22.02.04 07:18) [7]
> Каждый кусочек для одной связи. Это всего 8 байт на связь.

Не понял.

← →
Alex Konshin © (2004-02-22 07:31) [10]

Каждой стрелочке связи от элемента к элементу соответствует один кусочек. И чего тут непонятного?
Вопрос на засыпку: ты знаешь, что такое списки? Если нет - бегом читать книжку, иначе мы зря теряем время.

← →
Кен © (2004-02-22 07:40) [11]

> Alex Konshin © (22.02.04 07:31) [10]
> Каждой стрелочке связи от элемента к элементу соответствует
> один кусочек. И чего тут непонятного?

Какой "стрелочке" ?
Непонятно как хранить связи чтобы к ним был быстрый доступ по данным и наоборот. Непонятно как удалять связанные данные, как от дыр в них избавляться чтобы не сбивались связи. Всё непонятно.
Ищу компонент или что-нибудь, чтобы решало эти вопросы.

← →
Alex Konshin © (2004-02-22 07:48) [12]

Какие дыры в списках?
Еще раз: послушай совета и почитай про связные списки.
Извини, но у тебя слабая теоретическая подготовка, мне жаль тратить свое время на то, что ты можешь прочесть в любой книжке.

← →
Кен © (2004-02-22 07:56) [13]

> Alex Konshin © (22.02.04 07:48) [12]
> Какие дыры в списках?

Не в списках, а в данных. Читай внимательней. Если удаляешь часть своих данных ( массив одномерный ), то будет дыра. А если всё сдвинуть, то связи собъются, поэтому их надо корректировать.

← →
Alex Konshin © (2004-02-22 07:59) [14]

О господи!!! Я уже трижды пожалел, что открыл рот.
Какой-такой одномерный массив, если я говорю о списках?! В списках дырок не бывает!
НУ ТЕПЕРЬ ТЫ ПОНИМАЕШЬ, ЧТО ПОЧИТАТЬ ПРО СПИСКИ ТЕБЕ ПРОСТО НЕОБХОДИМО?

← →
Anatoly Podgoretsky © (2004-02-22 10:27) [15]

Alex Konshin © (22.02.04 07:59) [14]
На пользу, со временем у тебя образуется список, в каких случаях лучше рот не открывать.

← →
Alex Konshin © (2004-02-22 10:40) [16]

Да я подозревал, но подумал, а вдруг я неправ и мое превое впечатление обманчиво?
Ну, надеюсь, и ему это тоже на пользу.
Лучше посоветуй ему книжку какую-нибудь на эту тему. Просто, то что читаю в таких случаях я, для него будет просто издевательством (я имею в виду Кнута). Вроде у Вирта есть книжка, если мне память не изменяет - "Cтруктуры данных". Еще что-нибудь приходит на ум?

← →
Nous Mellon © (2004-02-22 11:06) [17]

Видимо Alex Konshin просто еще не знает кто такой Кен.
Alex не тратьте время зря...

← →
Думкин © (2004-02-22 11:20) [18]

> [16] Alex Konshin © (22.02.04 10:40)

Это жестокие книги. А вот Бакнелла почитать к примеру можно.

← →
Verg © (2004-02-22 11:27) [19]

http://www.cs.inf.ethz.ch/~wirth/books/AlgorithmE0/

← →
kaif © (2004-02-22 13:20) [20]

2 Кен ©
Речь шла о связанных списках, а не просто списках в виде массивов. В связанных списках каждый элемент списка, кроме себя, содержит еще, как минимум, указатель на другой элемент списка. Так как в таких списках все связи устроены с помощью указателей, удаление элемента не приводит к нарушению связей.

← →
Alexander666 © (2004-02-22 13:44) [21]

http://algolist.manual.ru/ - тоже немало инфы о списках

← →
DiamondShark © (2004-02-22 14:31) [22]

Лучше реляционной модели ещё ничего не придумали

2 DiamondShark © (22.02.04 14:31) [22]
Совершенно верно!
Хорошо бы еще выяснить, зачем понадобились все эти "связи". Может в основе постановки задачи вообще имеется какая-то шиза. Что за "дети многих родителей"? О чем вообще идет речь? А что если понадобится, чтобы ребенок этого родителя ни в коем случае не оказался правнуком их дедушек? Это будет посложнее реализовать, чем отсутствие циклических ссылок...

> Хорошо бы еще выяснить, зачем понадобились все эти "связи".

Это может быть долгим и весьма увлекательным занятием. :-)

Прелесть же реляционной модели как раз в том, что можно формально -- т.е. не напрягая мозги относительно шизы или быть может наоборот, врождённой гениальности -- построить хранилище.
Да ещё и производительность неплохую получить.

Впрочем, при всей мощи формальных методов думать всё-таки полезно. Тут спору нет.

> Alex Konshin © (22.02.04 07:59) [14]
> О господи!!! Я уже трижды пожалел, что открыл рот.
> Какой-такой одномерный массив, если я говорю о списках?!
> В списках дырок не бывает!

Оставь мои данные в покое !
Вопрос был не о том, как мне взять и переделать мои данные от нефига делать, а о связях между этими данными. Как организовать их ( связей, а не данных ) хранение, доступ, и обработку. Какие есть компоненты, или хоть что-нибудь, удобно это реализующие ? Какие есть демки ? Ответов нет.

> НУ ТЕПЕРЬ ТЫ ПОНИМАЕШЬ, ЧТО ПОЧИТАТЬ ПРО СПИСКИ ТЕБЕ ПРОСТО
> НЕОБХОДИМО?

То есть ты прочитал, дать ответа всё равно не можешь, и значит потратил время зря. А теперь тебе обидно, и ты хочешь, чтобы другие тоже зря потратили время ?

> Verg © (22.02.04 11:27) [19]
> http://www.cs.inf.ethz.ch/~wirth/books/AlgorithmE0/

Книга 1997 года на английском языке. Кликаю на ссылки, пишет Файл нот фаунд.

> Alexander666 © (22.02.04 13:44) [21]
> http://algolist.manual.ru/ - тоже немало инфы о списках

Статей пятьдесят там.

> DiamondShark © (22.02.04 14:31) [22]
> Лучше реляционной модели ещё ничего не придумали

Какой компонент можно посоветовать для удобной работы с этой моделью ?

> kaif © (22.02.04 14:38) [23]
> 2 DiamondShark © (22.02.04 14:31) [22]
> Совершенно верно!
> Хорошо бы еще выяснить, зачем понадобились все эти "связи".
> Может в основе постановки задачи вообще имеется какая-то
> шиза. Что за "дети многих родителей"?

А в чём собственно шиза ?
В жизни же никого не удивляет, когда разные события могут привести к одним и тем же последствиям.

Оставь мои данные в покое !
Вопрос был не о том, как мне взять и переделать мои данные от нефига делать, а о связях между этими данными. Как организовать их ( связей, а не данных ) хранение, доступ, и обработку. Какие есть компоненты, или хоть что-нибудь, удобно это реализующие ? Какие есть демки ? Ответов нет.

При чем тут твои данные?
Тебе ответили на вопрос и даже привели код. Не умеешь читать - твои проблемы.
Почему ты решил, что все должны броситься со всех ног помогать тебе и тратить свое время на разъяснение прописных истин, когда ты не хочешь даже палец о палец ударить? Тебе же ясно сказали, что у тебя нет знаний, чтобы просто понять то, что тебе говорят.

Ну, по крайней мере, я пытался до последнего. Совесть моя чиста.

Удалено модератором
Примечание: Хамить не надо

А ты еще не просто неуч, а неблагодарный неуч.
Чтож прозябай в невежестве дальше.
Тебе уже все сказали, ты просто понять этого не можешь.

> [29] Alex Konshin © (23.02.04 04:50)

#ifdef offtop
"Оставь надежду всяк сним говорящий".
Просто и в этой ветке и в соседней дело вскоре перейдет на личное и весьма некрасивое общение - чтобы не замараться - лучше в них больше не постить.
IMHO
#endif

Удалено модератором

Как, в чём хранить связи между данными ? Ведь количество связей Найти похожие ветки