|
|
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
Вот такая мысль меня посетила. (скорее всего это уже где-то было) Представим себе, что в БД есть только 2 таблицы. 1. Словарь (Код:Number,Понятие:Varchar,Словарь:Varchar) 2. Связь (Предок:Number,Потомок:Number) в которой Предок и Потомок справочные значения из таблицыСправочник. Добавим еще связь Связь.Потомок->Словарь.Код и связь Словарь.Код->Связь.Предок Тогда получается интересная связка в которой можно описать, если не все, то очень много. Например так выглядит такая схема в Кроносе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2008, 14:15 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
Надо еще оценить, наверное, время операций основных. Вставка, удаление, поиск... А что хотели получить? Просто способ представление адреса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2008, 19:56 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
Верно, начинал именно под адрес, а в итоге получилось более интересное решение. Под эту схему спокойно подпадает любой транспорт, любой товар/предмет, оружие и т.д. Даже Лицо и его связи в принципе можно рассматривать в таком представлении. Получилась этакая гиперлинковая база, где через ссылку на предка/потомка можно получить всю возможную информацию об объекте. Вот такакя загогулина 8-D ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2008, 20:17 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
Страдалецъскорее всего это уже где-то было Тогда получается интересная связка в которой можно описать, если не все, то очень много. Да, было, без малого полвека назад. Если добавить к этой замечательной идее мало-мальски адекватную реализацию, Вы получите иерархическую БД. Потом, если помните, вместо нее придумали более продвинутую - сетевую, потом еще более продвинутую - реляционную. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2008, 21:38 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
А теперь на Реляционной модели я построил древовидную, что подтверждает теорию эволюции по спирали. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2008, 21:59 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
мало понятно существо мысли. в зависимости от способа чтения она (мысль) либо тривиальна либо высказана не полностью. в той части, что связи между сущностями ( в предположении, что таблица [Словарь] представляет некую сущность) существуют в реляционной бд в виде таблиц - мысль тривиальна. Что называется - откройте учебник. (Это не в целях излишнего менторства, - я не нашел удачной формы для обозначения того факта, что таблица связи к таблице сущностей не стоила начала отдельного топика.) В той части, что представляемая схема описывает "если не все, то очень много" все становится неясно и недосказанно. Предположительно либо поле Словарь таблицы [Словарь] : [Словарь](Словарь:Varchar) либо поле Категория: [Словарь](Категория: Varchar) должно сегментировать таблицу Словарь на логически разные классы, которые можно мысленно представить находящимися в разных таблицах-представлениях сущностей В данном случае вероятная экономия состоит в экономии количества таблиц связей. Главный вопросы к такой схеме: - какой арности отношения описываются этой схемой в целом? - (если любой, то) каков механизм объявления и поддержки заявленной арности? Отсутствие (если вдруг) такого механизма означает отсутствие системы поддержки целостности информации в такой БД. Попытка использования стандартных, встроенных в БД механизмов (индексы + FK) наложит ограничение на тип связи и сведет применимость схемы от "очень много" до конкретного случая. вообще же, по сабжу много Garya размышлял. на русьимпорте есть картинки ( и вроде тезисы - лень искать) к его докладу, в котором он пытается вдохнуть жизнь в подобного сорта схематику. Но главного - платить рождением собственных механизмов управления в ответ на отказ от, говоря неформально, принипов разлождения информации по полкам, "даже он" не может избежать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2008, 22:41 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
СтрадалецъА теперь на Реляционной модели я построил древовидную, что подтверждает теорию эволюции по спирали. :-) Да, в одном прискорбно частом варианте. Проиллюстрирую его примером: Шаг 1. Берем молоток и забиваем гвоздь Шаг 2. Придумываем более удобные для автоматизации методы соединения (например, клепку и сварку) и оборудование для них. Шаг 3. Придумываем робота, умеющего соединять детали десятком разных техник. Шаг 4. Даем ему в руки молоток. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2008, 00:30 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
А я и не претендую на роль революционера в этой области. Это скорее просто вариант который может быть кому-то, где-то пригодится. Сваять что-то законченное только на подобной модели мне и самому затруднительно. Мне пока тоже непонятен механизм удобного поиска по такому дереву. Что касается ввода, удаления и т.д - здесь все нормально, я ведь схему брал из живой БД. Но что мне нравиться, это то что более удобного и гибкого способа хранения адресной информации я пока невидел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2008, 01:47 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
СтрадалецъА я и не претендую на роль революционера в этой области. Это скорее просто вариант который может быть кому-то, где-то пригодится. Сваять что-то законченное только на подобной модели мне и самому затруднительно. Мне пока тоже непонятен механизм удобного поиска по такому дереву. Что касается ввода, удаления и т.д - здесь все нормально, я ведь схему брал из живой БД. Но что мне нравиться, это то что более удобного и гибкого способа хранения адресной информации я пока не видел. Дерево будет несбалансировано, а значит и ряд проблем возникнет... Гибко - может быть, но вот время доступа - непонятно пока. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2008, 02:25 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
СтрадалецъА теперь на Реляционной модели я построил древовидную, что подтверждает теорию эволюции по спирали. :-) Эволюция велосипеда??? Буквари читать пробовал? Хотя бы на примере Oracle. Для начала с фразы CONNECT BY PRIOR. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2008, 14:55 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
softwarer Если добавить к этой замечательной идее мало-мальски адекватную реализацию, Вы получите иерархическую БД. Потом, если помните, вместо нее придумали более продвинутую - сетевую, потом еще более продвинутую - реляционную. По топу - согласен с Вами на все 100%. Но по оценке моделей данных - нет. Реляционная модель сейчас имеет отличную теоретическую базу, выдающиеся реализации и повсеместное распространение. Но не является вершиной "от иерархических к сетевым и реляционным БД". В частности, отсутствие удобной реализации работы с tree в реляционных БД (ANSI-SQL) - симптом того, что операторы работы с иерархическими данными нужны и не получили адекватную замену иерархии на реляцию. Хотя по сути иерархические отношения - это один из частных случаев отношений. Но запросы такого вида как "получить всех потомков для данного узла вглубину/вширину", "получить всех родителей", "получить корневой элемент", "проверить на ацикличность", "получить уровень листа" и т.п. в ANSI-SELECT не выражаются. (Хотя реализации я мельком где-то встречал в качестве расширения ANSI - не знаю насколько эффективные) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2008, 16:02 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
apapacyВ частности, отсутствие удобной реализации работы с tree в реляционных БД (ANSI-SQL) - симптом того, что операторы работы с иерархическими данными нужны и не получили адекватную замену иерархии на реляцию. Если коротко, Вы укоряете реляционные реализации тем, что работа с иерархиями в них реализована не лучше , чем в иерархических. Подчеркиваю: не "хуже", а "не лучше". apapacyХотя по сути иерархические отношения - это один из частных случаев отношений. Факт. И? apapacyНо запросы такого вида как "получить всех потомков для данного узла вглубину/вширину", "получить всех родителей", "получить корневой элемент", "проверить на ацикличность", "получить уровень листа" и т.п. в ANSI-SELECT не выражаются. Во-первых, если мне не изменяет память, в SQL2003 уже выражаются. Во-вторых, апелляция к ANSI SQL в таком контексте здорово напоминает капитуляцию. Ну и наконец, допустим, не выражаются - и что из этого? В иерархических БД это тоже отнюдь не атомы, а "подпрограммы". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2008, 17:54 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
Штудирую SQL2003. Пока не нашел способа запрашивать деревья. Если кто может просветить подробнее - сделайте это. Тут ведь дело не только в синтаксисе - важнее эффективность запросов. Tree - должно поддерживаться как 1) Тип данных 2) Язык запросов 3) Поддержка ускорения доступа к операциям над деревьями (что-то вроде индексов). Кстати IMS по-прежнему жива и, более того, используется - судя по наличным вакансиям - у нас. И IMS v10 идет в сторону ООБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2008, 23:42 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
apapacyШтудирую SQL2003. Пока не нашел способа запрашивать деревья. Я не помню термина, суть - рекурсивная ссылка в кляузе WITH. Что-то типа Код: plaintext 1. 2. 3. Мне так кажется, это уже включено в стандарт, хотя клясться не буду. apapacyТут ведь дело не только в синтаксисе - важнее эффективность запросов. Если мы говорим про эффективность, ANSI SQL тем более совершенно не при чем :) apapacyTree - должно поддерживаться как 1) Тип данных Спорно, весьма спорно. Деревья могут быть представлены несколькими разными реляционными структурами, у каждой свои достоинства. Будет ли "специальный тип данных" соединять эти достоинства и избегать недостатков - спорный вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2008, 01:51 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
автор1) тип данных... так кажется, что применительно к задаче Страдальца, как я ее впонял на текущий момент, заявление дерева как типа данных полностью эквивалентно записи адреса в виде простой строки: "г. Гатчина, Ингерманландской губернии, ул. Бульварная д xx/yy, Коробочке Настасье Петровне." с присобаченными к этой строке операциями вида "Извлечь из адреса город", "Извлечь ... улицу" и т.п. Сам по себе такой тип в любом представлении (напр. хемеель) имеет право быть. Вот только воспользоваться именно им в качестве верификатора/построителя его же содержимого вряд ли получится. Понадобится либо еще один тип, либо та или иная реляционно-множественная конструкция, задающая мир допустимых адресов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2008, 02:56 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
Страдалецъскорее всего это уже где-то было Ессно - мумпс называется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2008, 10:16 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
apapacyКстати IMS по-прежнему жива В IMS нет средств для работы с деревьями (а в оракле есть). зы вы путаете ИМД и возможность работы с деревьями - это вещи не связанные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2008, 10:22 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
softwarer apapacyВ частности, отсутствие удобной реализации работы с tree в реляционных БД (ANSI-SQL) - симптом того, что операторы работы с иерархическими данными нужны и не получили адекватную замену иерархии на реляцию. Если коротко, Вы укоряете реляционные реализации тем, что работа с иерархиями в них реализована не лучше , чем в иерархических. Подчеркиваю: не "хуже", а "не лучше". для меня очевидно, что все же отдельная ветка объектно-ориентированных серверов баз данных (в том числе и с поддержкой иерархий) будет развиваться. Важной ошибкой, имхо, у apapacy считаю перевод проблемы на операторы работы ... то есть синтаксическая (а не архитектурная) реализация поддержки иерархий. ps: по аналогии полнотекстовый поиск реализуется не через некий продвинутый оператор like, а отдельным сервисом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2008, 14:05 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
KGPдля меня очевидно, что все же отдельная ветка объектно-ориентированных серверов баз данных (в том числе и с поддержкой иерархий) будет развиваться. Бесспорно. Хотя иерархии тут имхо особо не при чем :) KGPВажной ошибкой, имхо, у apapacy считаю перевод проблемы на операторы работы ... то есть синтаксическая (а не архитектурная) реализация поддержки иерархий. Во-первых, я не вижу у него такого перевода, наоборот :) KGPps: по аналогии полнотекстовый поиск реализуется не через некий продвинутый оператор like, а отдельным сервисом. Ну, в Oracle это называется именно оператором Мне кажется, тут Вас очень неудачно перекашивает. SQL - декларативный язык, решения на нем подчеркнуто дистанциированы от реализации и допускают разные варианты физической реализации. Это то требование, которое должно быть сохранено и при реализации полнотекстового поиска, и при реализации деревьев. Появление в языке "операторов работы с деревьями" - в принципе независимо от появления в архитектуре "продвинутого хранилища деревьев", хотя в идеале они должны уметь особенно хорошо работать в паре. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2008, 14:45 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
softwarer Мне кажется, тут Вас очень неудачно перекашивает. SQL - декларативный язык, решения на нем подчеркнуто дистанциированы от реализации и допускают разные варианты физической реализации. Это то требование, которое должно быть сохранено и при реализации полнотекстового поиска, и при реализации деревьев. Появление в языке "операторов работы с деревьями" - в принципе независимо от появления в архитектуре "продвинутого хранилища деревьев", хотя в идеале они должны уметь особенно хорошо работать в паре. не заметил, да и в праздники воздерживался имхо в ms sql 2005 поддержка именно 'операторная', или вы уверены, что при работе с иерархией применяется что-то архитектурно новое? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2008, 15:00 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
Кстати, в mssql2008 появился _тип данных_ hierarchyid, со всеми необходимыми "деревянными" методами ("императивными", т.е. поддержка не 'операторная', если я правильно понял смысл этого термина как "декларативность"), инкапсулирующий иерархические отношения (между записями одной таблицы). Т.е. еще один, помимо рекурсивных CTE, "инструментарий", если здесь KGPимхо в ms sql 2005 поддержка именно 'операторная'они имелись в виду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2008, 16:47 |
|
||
|
Древовидная структура БД основанная на связанном списке.
|
|||
|---|---|---|---|
|
#18+
LR Кстати, в mssql2008 появился _тип данных_ hierarchyid, со всеми необходимыми "деревянными" методами ("императивными", т.е. поддержка не 'операторная', если я правильно понял смысл этого термина как "декларативность"), инкапсулирующий иерархические отношения (между записями одной таблицы). Т.е. еще один, помимо рекурсивных CTE, "инструментарий", если здесь KGPимхо в ms sql 2005 поддержка именно 'операторная'они имелись в виду. кратно и имхо удачно hierarchyid уже шаг более архитектурный, чем что-то типа Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2008, 16:55 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35047081&tid=1544100]: |
0ms |
get settings: |
7ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
23ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
71ms |
get tp. blocked users: |
1ms |
| others: | 225ms |
| total: | 361ms |

| 0 / 0 |
