Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Потрепаться";
Текущий архив: 2004.03.14;
Скачать: [xml.tar.bz2];

Вниз

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

 
Кен   (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]

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


 
kaif   (2004-02-22 14:38) [23]

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


 
DiamondShark   (2004-02-22 14:46) [24]


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

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

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

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


 
Кен   (2004-02-23 02:16) [25]


> 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]
> Лучше реляционной модели ещё ничего не придумали

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


 
Кен   (2004-02-23 02:30) [26]


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

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


 
Alex Konshin   (2004-02-23 03:17) [27]

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

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

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


 
Кен   (2004-02-23 04:32) [28]

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


 
Alex Konshin   (2004-02-23 04:50) [29]

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


 
Думкин   (2004-02-23 05:58) [30]

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

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


 
Кен   (2004-02-23 06:17) [31]

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



Страницы: 1 вся ветка

Форум: "Потрепаться";
Текущий архив: 2004.03.14;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.52 MB
Время: 0.015 c
14-43805
Kair
2004-02-23 09:05
2004.03.14
Оценка звука


7-43924
SkySlider
2003-12-22 13:14
2004.03.14
Обращение к принтеру


3-43369
griban
2004-02-15 15:56
2004.03.14
V C++builder bil QuickReport estj li ego nalog v B Delphi 7


3-43261
ИМХО
2004-02-13 03:31
2004.03.14
Пару слов о MS Access


3-43291
T{}r(l-l
2004-02-13 14:27
2004.03.14
Вопрос по таблицам Парадокса





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский