Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 [13] 14 15 16 17 .. 29   вперед  Ctrl
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
vadiminfo
Т.е. там все-таки дерево? Т.е. на самом деле
        o  
       / \
    а     b
     |     |
    с      c1
     |     |  
    d      e
?
Многлетняя привычка обходить табличную ограниченность идентификаторами? По вашей логике иерархическая структура в XML представляется не деревом, а графом?
vadiminfo
Или при чем тут разные Ивановы? И почему понятно, что они разные? Может оператор по ошибке одного в два места засандалила.
Надеюсь она не сама придумывает идентификаторы для новых сотрудников? И это называется верхний уровень абстракции?
vadiminfo
В SQL БД есть ограничения целостности
То, что там есть ограничения, мы с Вашей помощью узнаем все больше.
2 мар 06, 23:28    [2411111]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Ц4
Guest
2 okdoky :

узлы, помеченные 'c' в вашем "дереве" представляют одинаковые или разные сущности?
2 мар 06, 23:57    [2411143]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
?????
Guest
okdoky
Многлетняя привычка обходить табличную ограниченность идентификаторами? ...

Очередной ЧАЛ? Или просто юный хам???
3 мар 06, 00:02    [2411152]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okdoky

Многлетняя привычка обходить табличную ограниченность идентификаторами?

Это Вы типа как эксперт по таблицам и идентификаторам разбираетесь в многолетних привычках? Или просто дурочку запускаете? У Зигзага ведь нет ограниченностей? Особенно если забыть что он много не может как выяснилось ранее.
Задачу то внятно Вы так и не сказали. Инсерты и селекты свои не пояснили. Результат вам не нужен, но SQL-запрос зачем-то писали. Мож Вы не знаете вообще зачем их пишут? Даже не ясно действительно ли деревья Вы называли деревьями. А у других видим соринку в глазе? Ну может это поможет зигзагу. А что же еще?

okdoky

Надеюсь она не сама придумывает идентификаторы для новых сотрудников? И это называется верхний уровень абстракции?

Надежда умирает последней. Вы термин абстракция и верхний уровень употребляете так же беспечно как и деревья? Вставляем куда попало?


okdoky

То, что там есть ограничения, мы с Вашей помощью узнаем все больше.

Боюсь, что Вам действительно надо больше узнать о предмете обсуждения. Но мне, скорей всего, Вам уже не помоч при всем желании.
Органичения целостености - логические правила, которым должны удовлетворять данные БД. Например, что человеку не может быть 1000 лет. А не то, что Вы подумали. У Вас в Зигзаги нет таких органичений? Теперь ни чуть не удивлюсь.
3 мар 06, 00:47    [2411225]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
Rus000

именно так. Под индексом я понимаю структуру, инвертированную по отношению к основной, способом иной группировки ключевых выражений

Да, но к сожалению весь СУБД мир (а это почти на 100% РСУБД мир) понимает индекс не так как Вы.

Еще раз повторяю, то что Вы называете индексированием доступно и в РСУБД, более того это известный метод и его рекомендуется использовать в некоторых случаях, но только как исключение, поскольку поддерживать целостность приходится руками. Точнее почти всегда триггерами, но это в принципе то же самое. А стандартно лучше обходится нормальными индексами, пусть у СКЛ сервера голова болит о целостности данных и индекса, он для этого и придуман.

Rus000

Вопрос терминов. Думаю в РСУБД все обстоит абсолютно аналогично, за исключением того, что в SQL это скрыто на уровне реализации страндарта.
Предложения SQL - суть высокоуровневые процедуры. Мы пытаемся сейчас копаться в более низких слоях

Простите, не мы, а Вы. Уровень решения задачи в кеше был выбран Вами. В СКЛ-е копаться на низком уровне бессмысленно, этого уровня в нормальном коммерческом СКЛ сервере в доступном виде вообще нет. Можно посмотреть план запроса, но это не совсем копание на низком уровне.

Rus000

Конечно же не хитрю. В моем понимании индексов (см.выше) это классический инверсный индекс, который позволяет оптимизировать скорость запроса.

Только разница в том, что индекс поддерживается СКЛ сервером, а Ваша структура - программистом.

Rus000

Оптимизатор SQL делает примерно такой же анализ по какой индексной структуре или их комбинации обработать запрос

Вот именно что оптимизатор, а не программист, как в М.

Rus000

Безусловно все быглядит куда более понятнее и лаконичнее, но мы сравниваем несколько разные вещи. Гораздо интереснее было б взглянуть на сгенерированный низкоруовневый год для этих запросов.

Я даже не знаю систем, где этот код доступен для обозрения. План запроса можно посмотреть, но это другое.

Мы же хотим сделать жизнь человека легче. Есть средство, котрое что-то делает за человека, причем в данном случае вполне эффективно. Вот пусть оно и работает. А Вы предлагаете смотреть как оно работает. Если Вы пишите базы данных, а не оптимизаторы запросов, то это трата времени. У БД программиста есть более полезные, а главное высокооплачиваемые занятия, чем копаться в низкоуровневом коде.

Rus000

Ваши примеры будут работать, например, и в кашовом SQL, но в любом случае СУБД должна сгенерировать исполняемы код, который выдаст искомы результат.

Во-первых только что выяснили, что далеко не все примеры будут работать в кешовом СКЛ-е. Эти может и будут, а другие - нет.
Во-вторых есть еще вопрос производительности. Не поверю что кешовый СКЛ, который кое-как из коммерческих соображений прикручен сбоку к иерархической БД будет работать так же быстро как оптимизируемый несколько десятков лет СКЛ в РСУБД, где он "родной" язык.
В-третьих какое мне дело куда транслируется СКЛ, если в результате программа работает достаточно быстро. Я пишу на СКЛ-е и вниз не лезу. В этом же весь смысл, чтоб я меньше работал и больше успел.

Rus000

да, упустил, ночью писал, но это не принципиально, согласитесь, достаточно добавить фильтр по условию в $$COUNT(path,filter) и указать в качестве фильтра статус=2 (продан)

Напишите по-возможности как будет в М стиле, я же вообще ничего об М не знаю, а тут фильтры.
3 мар 06, 07:33    [2411445]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Ц4
2 okdoky :
узлы, помеченные 'c' в вашем "дереве" представляют одинаковые или разные сущности?
Аналогичный вопрос. Кто-нибудь четко условия сформулирует? Эти узлы c - фактически одна и та же сущность, или две разные, но имеющие просто неуникальный атрибут вроде "название" с свпадающими значениями 'c'? Если это одно и то же, то как эта сущность вообще попала в разные места графа (забудет про про деревья, будем говорить о графе)? Ведь вершины в графе по определению входят в множество вершин, следовательно все вершины различны и различимы, и одна и та же вершина не может присутствовать дважды. По определению.
3 мар 06, 08:01    [2411497]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
mir
Ц4
2 okdoky :
узлы, помеченные 'c' в вашем "дереве" представляют одинаковые или разные сущности?
Аналогичный вопрос. Кто-нибудь четко условия сформулирует? Эти узлы c - фактически одна и та же сущность, или две разные, но имеющие просто неуникальный атрибут вроде "название" с свпадающими значениями 'c'? Если это одно и то же, то как эта сущность вообще попала в разные места графа (забудет про про деревья, будем говорить о графе)? Ведь вершины в графе по определению входят в множество вершин, следовательно все вершины различны и различимы, и одна и та же вершина не может присутствовать дважды. По определению.
Согласен с mir. Конечно две вершины, даже одинаковые (с одним именем, одного цвета) обозначают не одну сущность. По-моему весь спор из-за разного понимания принципов идентификации. Если у меня есть два сыра, чтобы их идентифицировать мне достаточно сказать, что один сыр находится в левом кармане, а другой в правом. Я не обязан придумывать имена или идентификаторы типа №1256794290 как это принято в РБД.
3 мар 06, 08:30    [2411555]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
мод
Guest
Как выяснилось граф оказался М не зубам. Вот пример попроще.
Есть картотека персонала 100 полей уникальный № поиск возможен по некоторым полям.
Решение для РБД тривиально: таблица на 100 полей уник. индекс по № индексы по полям поиска. Все.
Решение для М я знаю :) но хочется сначала послушать М-технологов.
Ждемс.
3 мар 06, 09:22    [2411691]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
okdoky
mir
Ц4
2 okdoky :
узлы, помеченные 'c' в вашем "дереве" представляют одинаковые или разные сущности?
Аналогичный вопрос. Кто-нибудь четко условия сформулирует? Эти узлы c - фактически одна и та же сущность, или две разные, но имеющие просто неуникальный атрибут вроде "название" с свпадающими значениями 'c'? Если это одно и то же, то как эта сущность вообще попала в разные места графа (забудет про про деревья, будем говорить о графе)? Ведь вершины в графе по определению входят в множество вершин, следовательно все вершины различны и различимы, и одна и та же вершина не может присутствовать дважды. По определению.
Согласен с mir. Конечно две вершины, даже одинаковые (с одним именем, одного цвета) обозначают не одну сущность. По-моему весь спор из-за разного понимания принципов идентификации. Если у меня есть два сыра, чтобы их идентифицировать мне достаточно сказать, что один сыр находится в левом кармане, а другой в правом. Я не обязан придумывать имена или идентификаторы типа №1256794290 как это принято в РБД.

это точно сказано
две вершины дерева - безусловно разные сущности
вопрос в удобстве-неудобстве обозначений

все же как правильно в SQL создать дерево ?
в М надо записать :
set T(a,b,s,d)=Q для каждой ветви короткой или длинной
или выполнить команду MERGE :
merge T(a,b,c)=T2(s,t,u)
- к узлу "с" дерева "Т" прицепит узел "s" дерева "Т2" со всеми его ветвями

а как в SQL ?
3 мар 06, 09:25    [2411701]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
c127

[quot Rus000]
именно так. Под индексом я понимаю структуру, инвертированную по отношению к основной, способом иной группировки ключевых выражений

Да, но к сожалению весь СУБД мир (а это почти на 100% РСУБД мир) понимает индекс не так как Вы.
[/qout]

старался никогда не говорить за всех ... у Вас есть под рукой определение термина <i>индекс</i>? Может начнем с этого?


Еще раз повторяю, то что Вы называете индексированием доступно и в РСУБД, более того это известный метод и его рекомендуется использовать в некоторых случаях, но только как исключение, поскольку поддерживать целостность приходится руками. Точнее почти всегда триггерами, но это в принципе то же самое. А стандартно лучше обходится нормальными индексами, пусть у СКЛ сервера голова болит о целостности данных и индекса, он для этого и придуман.


Безусловно, Вы говорите все правильно, голова должна болеть у оптимизатора, а не у программиста, но я Вам привел подход к решению на чистом (почти) M, который является аналогом кода генерируемом РСУБД после парсинга запросов. В этом был академический интерес, так?
Я же не утверждал, что m-проргаммеры используют такой или только такой подход. Нет, конечно. Можно было бы решить эту задачу в терминах классов , и тогда у нас бы тоже голова не болела о поддержке логической целостности данных. Мне казалось Вы понимаете, что мы разбираемся в потрохах для понимания принципов, а не для того чтобы говорить что СКЛ лучше, потому что он позволяет скрыть многие ненужные детали. Я же эти подходы не противопоставлял - они суть не противоречат друг другу, т.к. стандарт СКЛ может быть реализован на M, обратное не верно.

c127

Мы же хотим сделать жизнь человека легче. Есть средство, котрое что-то делает за человека, причем в данном случае вполне эффективно. Вот пусть оно и работает. А Вы предлагаете смотреть как оно работает. Если Вы пишите базы данных, а не оптимизаторы запросов, то это трата времени. У БД программиста есть более полезные, а главное высокооплачиваемые занятия, чем копаться в низкоуровневом коде.


Ну я бы сказал, что мерилом является эффективность решения и скоорость его реализации при заданных граничных условиях его эксплуатации, в т.ч. технических, а не то, в чем именно копаться программерам.

Вот еще насчет сокрытия ненужных деталей. Прочел любопытную [url=http://]статью [/url] - понравился "алгоритм Шлемиеля"

с127

Во-вторых есть еще вопрос производительности. Не поверю что кешовый СКЛ, который кое-как из коммерческих соображений прикручен сбоку к иерархической БД будет работать так же быстро как оптимизируемый несколько десятков лет СКЛ в РСУБД, где он "родной" язык.


ну, "не поверю" - это конечно слабый аргумент :)
предположим даже что эта реализация sql чуть менее эффектива, но зато мы получаем гибридную систему в которой есть и способы представления данных в иерархии, и в реляционных отношениях и в объектной парадигме. Получаем некое МФУ (многофункциональное устройство), по аналогии с принтер/копир/факс, т.е. получаем большую свободу выбор в реализации проектов...чем плохо-то?
3 мар 06, 10:37    [2412035]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
забыыл указать ссылку на статью Джоэла
3 мар 06, 10:49    [2412154]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Rus000
забыыл указать ссылку на статью Джоэла

Джоель изобрел функцию stpcpy ))) Отец!
3 мар 06, 12:06    [2412843]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
okdoky
Если у меня есть два сыра, чтобы их идентифицировать мне достаточно сказать, что один сыр находится в левом кармане, а другой в правом. Я не обязан придумывать имена или идентификаторы типа №1256794290 как это принято в РБД.
В который раз вы выказываете потрясающе слабое владение предметом, который критикуете.
Итак, подробнее. Предметы, которые человек сам для себя идентифицирует в реальном мире просто по их местоположению, не обязательно нуждается в "придумывании" формальных идентификаторов. В вашем примере, вы различаете сам для себя куски сыра по их очевидной пространственной привязке. Однако попробуйте эту информацию преобразовать в данные, то есть любым образом закодировать. И тут же вы обнаружите, что так или иначе изобретете при этом идентификаторы вроде строк "кусок в левом кармане" и "кусок в правом кармане". По вашему, это не идентификаторы? А что же это? Без каких-либо идентификаторов вам не удасться ни сохранить данные об этих кусках сыра, ни передать эти данные кому-либо, ни, следовательно, работать с ними. И как же в этом будет "виновата" РБД? Да пораскиньте же мозгами, прежде чем что-либо подобное утверждать, глядишь, думать и понравиться :)
А по поводу идентификаторов вроде №1256794290, которые сами по себе вроде не имеют смысла, так они встречаются в реальной жизни и безо всяких РБД. Номера автомобилей, паспортов, ИНН, СПС, рейсов самолетов, маршрутов пассажирского транспорта... И миллион подобных примеров, многие из которых имеют историю длиннее не только РМД, но и компьютеров вообще. Подумайте, подумайте над этим, думать полезно.
3 мар 06, 12:23    [2412941]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
okdoky
Если у меня есть два сыра, чтобы их идентифицировать мне достаточно сказать, что один сыр находится в левом кармане, а другой в правом. Я не обязан придумывать имена или идентификаторы типа №1256794290 как это принято в РБД.
В который раз вы выказываете потрясающе слабое владение предметом, который критикуете.
Итак, подробнее. Предметы, которые человек сам для себя идентифицирует в реальном мире просто по их местоположению, не обязательно нуждается в "придумывании" формальных идентификаторов. В вашем примере, вы различаете сам для себя куски сыра по их очевидной пространственной привязке. Однако попробуйте эту информацию преобразовать в данные, то есть любым образом закодировать. И тут же вы обнаружите, что так или иначе изобретете при этом идентификаторы вроде строк "кусок в левом кармане" и "кусок в правом кармане". По вашему, это не идентификаторы? А что же это? Без каких-либо идентификаторов вам не удасться ни сохранить данные об этих кусках сыра, ни передать эти данные кому-либо, ни, следовательно, работать с ними. И как же в этом будет "виновата" РБД? Да пораскиньте же мозгами, прежде чем что-либо подобное утверждать, глядишь, думать и понравиться :)
А по поводу идентификаторов вроде №1256794290, которые сами по себе вроде не имеют смысла, так они встречаются в реальной жизни и безо всяких РБД. Номера автомобилей, паспортов, ИНН, СПС, рейсов самолетов, маршрутов пассажирского транспорта... И миллион подобных примеров, многие из которых имеют историю длиннее не только РМД, но и компьютеров вообще. Подумайте, подумайте над этим, думать полезно.
3 мар 06, 12:24    [2412953]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
mir

И тут же вы обнаружите, что так или иначе изобретете при этом идентификаторы вроде строк "кусок в левом кармане" и "кусок в правом кармане". По вашему, это не идентификаторы?

Особенно если он наложит в один корман много кусков или из всех корманов выложит все на стол. Они там в зигзаге похоже изобретают велосипеды давно и конкретно. Что-то я теперь не уверен, что с проетированием БД там все у зигзаговцев так хорошо, что Скуль умирает от звависти. Это не реально.
3 мар 06, 13:53    [2413568]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
vadiminfo
mir

И тут же вы обнаружите, что так или иначе изобретете при этом идентификаторы вроде строк "кусок в левом кармане" и "кусок в правом кармане". По вашему, это не идентификаторы?

Особенно если он наложит в один корман много кусков или из всех корманов выложит все на стол. Они там в зигзаге похоже изобретают велосипеды давно и конкретно. Что-то я теперь не уверен, что с проетированием БД там все у зигзаговцев так хорошо, что Скуль умирает от звависти. Это не реально.

вот когда надо достать из кармана
тогда М и прицепит идентификатор -
полную адресную ссылку по дереву - все ветви сверху донизу
а если мало дерева - еще и код базы данных добавит
не придурки же М создавали
в конце концов
А если его из штанов доставать не надо -
зачем ему сразу клеить идентификатор
x556у57868й97гппщ90грн86ап7898 ?

Кстати
как все же правильно в SQL создать дерево ?
нарисуйте пожалуйста
кто может
==============
3 мар 06, 14:44    [2413992]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ggv
Member

Откуда:
Сообщений: 1810
google рулит.
на просторах инета встречались мне больше одной описания создания древовидных структур в RDBMS.
Более-менее тесно я ковырялся в одной, на основе которой создан IBM Tivoly Directory Server - имплементация LDAP (лучшая имплементация)
А LDAP, если mumps-исты знают, это прежде всего иерархия.
Да, разработчики очень подробно написали, как они, используя RDBMS IBM DB2 создают иерархические структуры для LDAP.
еще раз - google рулит.
Да, есть же кажись и у Oracle реализация LDAP. Она небось тоже на основе RDBMS Oracle, ибо нет ничего такого, чего нельзя бы было разложить по таблицам RDBMS.
(не я сказал, это все Кодд утверждал)
3 мар 06, 15:06    [2414117]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ggv
Member

Откуда:
Сообщений: 1810
рисовать не буду - влом, sorry, спешу.
То есть до вторника факт не буду, а к тому времени только еще более ленивый чем я не найдет в инете :)
3 мар 06, 15:07    [2414126]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
мод
Guest
[quot MX -- ALEXКстати
как все же правильно в SQL создать дерево ?
нарисуйте пожалуйста
кто может
[/quot]
Причем тут SQL ?
Дерево - одна таблица (файл, сегмент) со ссылкой на родителя (всегда одного в дереве!).
Ориентированный граф - две таблицы (файла, сегмента): вершины и связи между вершинами.
А вот пример посложнее:
Есть картотека персонала 100 полей уникальный № поиск возможен по некоторым полям.
Решение для РБД тривиально: таблица на 100 полей уник. индекс по № индексы по полям поиска. Все.
Решение для М я знаю :) но хочется сначала послушать М-технологов.
Ждемс.
3 мар 06, 15:44    [2414373]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
MX -- ALEX

А если его из штанов доставать не надо -
зачем ему сразу клеить идентификатор
x556у57868й97гппщ90грн86ап7898 ?

В РБД есть понятие естествеенного и суррогатного идентификатора. Это дело проектировщика. Хотите никак не идентифицируйте. Принуждать РБД не будет. Но идентификаторы- это понятие не тока РБД. Наскока я знаю, оно имеет значение для объектов или сущностей, чтобы их отличать вообще.

MX -- ALEX

Кстати
как все же правильно в SQL создать дерево ?
нарисуйте пожалуйста
кто может

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


Например
 ID  ID_ID Other
-----------
  1            aaa
  2     1     bbbb
  3     2     vvvv
1 непосредственный предок 2, 2 - 3.
Здесь ID - идентификатор.
Это связь один ко многим. Т.е. есть общие непосредственные предки для разных узлов. Но нет множественного наследования. Здесь конечно и петлю можно впендюрить. Но тада нужно принимать меры от зацикливания в запросах

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

Собсно okdoky и рисовал такую. Тока потом сказал непонятно че. Из его тескста следовало, то что он ваще не про деревья. А потом и вовсе его тексты облачились в туман.
3 мар 06, 15:57    [2414474]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
MX -- ALEX
вот когда надо достать из кармана
тогда М и прицепит идентификатор - полную адресную ссылку по дереву - все ветви сверху донизу а если мало дерева - еще и код базы данных добавит
не придурки же М создавали в конце концов А если его из штанов доставать не надо - зачем ему сразу клеить идентификатор x556у57868й97гппщ90грн86ап7898 ?
Если не секрет, это всё к чему вы написали? То ли с кем-то спорите, то ли это поток сознания такой? И кто вас заставлял куда-то там "клеить" идентификатор x556у57868й97гппщ90грн86ап7898?
3 мар 06, 16:19    [2414631]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
MX -- ALEX
Кстати
как все же правильно в SQL создать дерево ?
нарисуйте пожалуйста
кто может


Поскольку SQL не основан на хранении именно деревьев, то их реализация может быть разной. Например.

1. Самый простой способ - делать как в кеше. Задаём некий разделитель, допустим "/". Стуктура таблицы:
create table tree(
path varchar(99), 
attr varchar(9))
Тогда вставка делается просто - по аналогии с set T(a,b,s,d)=Q:
insert tree select 'a/b/s/d', 'Q' 
Выборка тоже проблем не составляет. Но довольно проблемно переносить ветки из одной в другую.

2. Способ когда гарантируется (задачей) уровень вложенности. Можно использовать например для бухгалтерских счетов:
create table tree(
level1  varchar(9), 
level2  varchar(9), 
level3  varchar(9), 
level4  varchar(9), 
attr varchar(9))
Вставка тоже делается просто
insert tree select 'a','b','s','d', 'Q' 
, перенести не сложно
update tree set level3='x' where level1='a',level2='b',level3='s',level4='d'
, но уровень вложенности ограничен и при переносе не поменять уровень. Зато можно сделать нужные индексы по любому сочетанию полей и делать эфективные выборки.
Кстати может быть не одна, а несколько таблиц - каждая на свой уровень.

3. Способ связи родитель-потомок(пример для MS SQL). Самый распространённый(у меня :) способ реализации деревьев, несмотря на казалось бы большие сложности
create table tree(
id int identity, -- поле счетчик
parent int null,
attr varchar(9))
вставка
insert tree select null,'a'
insert tree select @@identity,'b' 
insert tree select @@identity,'s'
insert tree select @@identity,'d'
insert tree select @@identity,'Q'
@@identity - системная переменная, содержит последнее значение счетчика
добраться до аттрибута может показаться довольно сложным (На Оракле или Юконе с рекурсивными(иерархическими) запросами будет наверное проще):
select t4.* from tree t1
join tree t2 on t2.parent= t1.id and t2.attr='b'
join tree t3 on t3.parent= t2.id and t3.attr='s'
join tree t4 on t4.parent= t3.id and t4.attr='d'
where t1.parent is null and t1.attr='a'
Но на самом деле имено так не делается - уверен что любого SQL-щика покоробили условия типа t4.attr='d' - я их писал только для полной аналогией с T(a,b,s,d). Обычно на клиент вместе с выборкой данных идет и идентификатор(id), которого вы (М-овцы) так боитесь и с ним клиент и оперирует.

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

Хотя в любом случае позаписная обработка на SQL будет проигрывать процедурным языкам - на SQL надо с данными, а не с записями работать.
3 мар 06, 16:46    [2414809]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
Спасибо SergSuper , vadiminfo
теперь яснее
3 мар 06, 16:59    [2414888]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
токарь
Guest
SergSuper, vadiminfo и др: Со сложными полями типа SET или ROW Вы не работали? Элементами SET могут ли быть другие SET? Можно ли представлять нижний уровень каждой вершины отдельной таблицей? Тогда очевидно, опять придется самому идентифицировать (именовать) каждую вершину? Пострадает ли от этого быстродействие?
3 мар 06, 17:48    [2415126]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
токарь
SergSuper, vadiminfo и др: Со сложными полями типа SET или ROW Вы не работали? Элементами SET могут ли быть другие SET? Можно ли представлять нижний уровень каждой вершины отдельной таблицей? Тогда очевидно, опять придется самому идентифицировать (именовать) каждую вершину? Пострадает ли от этого быстродействие?

А можно как-нибудь задать вопрос ближе к прикладной области? Я в теориях не силён.
Таблица - это же тоже некая условность для представления какой-то информации. Давайте опишите задачу, будет понятней что вы хотите
Не надо приписывать мне мышление табличными категориями :)

Что касается опять придется самому идентифицировать (именовать) каждую вершину - у меня в 3-м примере каждая вершина сама идентифицируется, это делается встроенными в MS SQL механизмами - identity. В Оракле тоже есть подобный механизм, не такой тривиальный, но с несколько большими возможностями. Так что быстродействие не страдает
3 мар 06, 18:26    [2415281]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 8 9 10 11 12 [13] 14 15 16 17 .. 29   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить