Комментарии 35
А как это соотносится со стандартами на SQL? Или ещё одна несовместимая ни с чем другим фича?
много вы знаете баз данных, которые реализуют только стандарты и ничего больше?
это решение от разработчиков MS SQL, крайне любопытное и интересное, как и другие новые типы 2008 сиквела
это решение от разработчиков MS SQL, крайне любопытное и интересное, как и другие новые типы 2008 сиквела
Стандарты SQL не будет полностью поддерживаться не в какой базе данных как минимум потому, что внутренне устройство базы данных вносит те или иные тонкости в "реализацию" стандартов.
Забудьте вы про стандарты. Никакую задачу сложнее Guestbook'а никто не будет решать "по стандартам" - если он в здравом уме и твёрдой памяти. Все эти потуги на переносимость приводят только к тому, что тратится в 10 раз больше ресурсов, чем могло бы.
Всё равно приходится затачивать всё под используюму СУБД - будь то MS SQL, MySQL или Oracle. Я сам бы использовать MS SQL не стал (прежде всего потому что он под нормальными OS не работает), но если кто-то его пользует и хочет реализовывать иерархические структуры с помощью этого расширения - почему бы и нет?
Всё равно приходится затачивать всё под используюму СУБД - будь то MS SQL, MySQL или Oracle. Я сам бы использовать MS SQL не стал (прежде всего потому что он под нормальными OS не работает), но если кто-то его пользует и хочет реализовывать иерархические структуры с помощью этого расширения - почему бы и нет?
НЛО прилетело и опубликовало эту надпись здесь
приз получит тот, кто напишет в комментариях, в чем этот метод проигрывает классическому ;)
Ну например, с помощью этой штуки можно достать все элементы третьего уровня с помощью элементарного запроса без всяких join'ов.
Ещё: имея только hid элемента дерева вы уже знаете на каком уровне он расположен, не прибегая к простмотру дерева вверх или всяким вспомогательным таблицам.
Ещё: имея только hid элемента дерева вы уже знаете на каком уровне он расположен, не прибегая к простмотру дерева вверх или всяким вспомогательным таблицам.
непереносимостью, конечно!
Это только синтаксис, или отпечаток такой бд на винте оптимизирован под навигацию по графу? Ну то есть, общая проблема реляционной базы данных в хранении графов вообще и деревьев в частности в том, что при вычитывании "цельного" куска графа мы имеем много-много страшных и противных random access-ов к винту, что убивает производительность на корню. Вот это решение от MS - это просто синтаксис к классическим форматам хранения данных в реляционных базах, или именно честный механизм сериализации дерева на винт?
Для выборки произвольного целого поддерева детей за 1 запрос — тоже есть простые решения, которые не будут вешать винт, и не про них «сразу ясно, что это всё будет глючить и тормозить» © чьи-то.
Тоже интересно, реализация ли это деревянного хранения объектов ли это
Тоже интересно, реализация ли это деревянного хранения объектов ли это
при вычитывании "цельного" куска графа мы имеем много-много страшных и противных random access-ов к винту, что убивает производительность на корню.
При выполнении обычного select тоже идет random access к винту и ничего. Это проблема не РСУБД, это проблема отдельного решения.
Вспомнилось
- Ненавижу кошек
- Ты просто не умеешь их готовить.
при выполнении обычного селекта доступ более-менее последовательный. солите своих кошек :)
Вы можете показать грань между "более-менее последовательный доступ" и "random access"?
Обычный селект:
необходимо вытащить информацию о начислениях/оплатах и пр. по услугам лицевого счета за месяц - 20-100 строк. Данных за месяц 5-6млн. Данные вносятся постепенно в течении месяца.
Где здесь "более-менее последовательный" доступ? Учитывайте, что параллельно выполняется несколько запросов, которые тоже требуют доступа к диску.
Для нивелирования затрат доступа к диску есть решения как уровне железа, так и на уровне ПО СУБД, но если неоптимальное решение генерирует тучу ненужных обращений к данным, то последовательное расположение данных на диске не решит проблему.
Обычный селект:
необходимо вытащить информацию о начислениях/оплатах и пр. по услугам лицевого счета за месяц - 20-100 строк. Данных за месяц 5-6млн. Данные вносятся постепенно в течении месяца.
Где здесь "более-менее последовательный" доступ? Учитывайте, что параллельно выполняется несколько запросов, которые тоже требуют доступа к диску.
Для нивелирования затрат доступа к диску есть решения как уровне железа, так и на уровне ПО СУБД, но если неоптимальное решение генерирует тучу ненужных обращений к данным, то последовательное расположение данных на диске не решит проблему.
Нет. Очень сильно зависит от реализации, но, тем не менее, записи обычно располагаются в порядке добавления.
Стоит, например, "попросить" записи в другом порядке, и "обычный" select будет прыгать по диску туда-сюда.
Стоит, например, "попросить" записи в другом порядке, и "обычный" select будет прыгать по диску туда-сюда.
Обартите внимание на hierarchyid::GetRoot()...
Гениально! Спасибо, что поделились таким чудесным знанием :)
Было бы интересно сравнение по производительности с классическими методами.
Например, я хочу выбрать всех потомков элемента, или всех родителей до корня. Что быстрее, использование нового подхода MSSQL2008 или хранение иерархии в четыре столбца: Id, parentId, startId, finishId с классическим запросом на принадлежность элемента диапазону??
Например, я хочу выбрать всех потомков элемента, или всех родителей до корня. Что быстрее, использование нового подхода MSSQL2008 или хранение иерархии в четыре столбца: Id, parentId, startId, finishId с классическим запросом на принадлежность элемента диапазону??
НЛО прилетело и опубликовало эту надпись здесь
Вполне нормальное расширение РБД. В PostgreSQL поддерживается "наследование" таблиц — на мой взгляд, одна из тех возможностей, которых так не хватает прочим большим SQL-серверам. А в данном случае, MS, вероятно, просто пытается нагнать Oracle, где подобное решение существует уже давно. Ну и слава богу.
о, кстати, если вы в курсе, можно в двух словах про Оракл написать? Какое там решение через что реализуется?
http://www.orafaq.com/wiki/SQL_FAQ#How_d…
Я по Oracle не специалист, но знаю, что там иерархические структуры поддерживаются
уже давно. На самом деле, и в MS SQL 2005, благодаря рекурсивным запросам можно
организовать иерархическую таблицу. В MS SQL 2008 всё это упростили в конце концов.
Я по Oracle не специалист, но знаю, что там иерархические структуры поддерживаются
уже давно. На самом деле, и в MS SQL 2005, благодаря рекурсивным запросам можно
организовать иерархическую таблицу. В MS SQL 2008 всё это упростили в конце концов.
там есть CONNECT BY PRIOR конструкция для рекурсивных запросов.
Тем кому нужно хранить много древовидной информации, советую обратить внимание на БД Sedna
http://www.phpconf.ru/u/_files/files/0/2…
http://www.phpconf.ru/u/_files/files/0/2…
ссылка умерла :(
Вот сохраненная в гугле версия презентации http://64.233.183.104/search?q=cache:XRHNJBDbo-AJ:http://www.phpconf.ru/u/_files/files/0/2…
А вот офсайт http://modis.ispras.ru/sedna/
Вот сохраненная в гугле версия презентации http://64.233.183.104/search?q=cache:XRHNJBDbo-AJ:http://www.phpconf.ru/u/_files/files/0/2…
А вот офсайт http://modis.ispras.ru/sedna/
Хм, все, кому надо хранить иерархическую информацию, советую старый добрый LDAP, и ничего не надо придумывать!
Если мог бы плюсовать - обязательно плюсанул бы Автору топика!!
Благодарен за статейку.
Минус тем кто не понимает прелести данной фичи.
Если MySQL бы еще такую штуку к себе бы прикрутила, тогда бы DBTree шла бы лесом, тогда бы струтура сайта в сто раз проще было бы сделать, тогда бы еще много чего наваять можно было бы!
Акститесь те кто говорит что это на производительность повлияет! Впомните любой пример кода на РНР для выбоки дерева каталога товаров для интернет магазина, это жесть ведь! Вот где производительность теряется!
Благодарен за статейку.
Минус тем кто не понимает прелести данной фичи.
Если MySQL бы еще такую штуку к себе бы прикрутила, тогда бы DBTree шла бы лесом, тогда бы струтура сайта в сто раз проще было бы сделать, тогда бы еще много чего наваять можно было бы!
Акститесь те кто говорит что это на производительность повлияет! Впомните любой пример кода на РНР для выбоки дерева каталога товаров для интернет магазина, это жесть ведь! Вот где производительность теряется!
Для PHP/MySQL я когда-то придумал неплохое решение. Понятно, что не без недостатков, но SELECT'ы там работали быстро.
Ключевое поле было типа CHAR(N), N — максимальная глубина вложенности. Каждый символ задавал порядковый номер узла в родительском узле в M-ричной системе исчесления (M — максимальное количество дочерних узлов). Если M=10, то идентификаторы могли быть, например, такими:
0
00
01
010
011
012
02
021
03
Проблемы возникали при добавлении и удалении узлов, но в условиях, когда добавление/удаление происходит редко, они были не такими существенными. Зато SELECT'ы работали быстро:
SELECT * FROM ProductGroups WHERE id LIKE '02%' — выбрать всех потомков узла 02, включая его самого
SELECT * FROM ProductGroups WHERE id LIKE '02_' — выбрать только детей 02
Такой метод работает быстро.
Ключевое поле было типа CHAR(N), N — максимальная глубина вложенности. Каждый символ задавал порядковый номер узла в родительском узле в M-ричной системе исчесления (M — максимальное количество дочерних узлов). Если M=10, то идентификаторы могли быть, например, такими:
0
00
01
010
011
012
02
021
03
Проблемы возникали при добавлении и удалении узлов, но в условиях, когда добавление/удаление происходит редко, они были не такими существенными. Зато SELECT'ы работали быстро:
SELECT * FROM ProductGroups WHERE id LIKE '02%' — выбрать всех потомков узла 02, включая его самого
SELECT * FROM ProductGroups WHERE id LIKE '02_' — выбрать только детей 02
Такой метод работает быстро.
Вот еще интересный вопрос: насколько быстро это дерево обновляется - например, при изменении подчиненности какого-либо узла. Помнится, в MS SQL была такая вещь, как Materialazied View - при выборке данных все было шИкарно ((c) переводчик на МТВ), а вот при обновлении были жуткие тормоза..
Отлично!
Для PostgreSQL есть модуль ltree: http://www.sai.msu.su/~megera/postgres/gist/ltree/
Реализует организацию строк в деревья, структура пути похожа: Top.Countries.Europe.Russia.
Для выборки элементов можно использовать хитрые запросы типа Top.*{0,2}.sport*@.!football|tennis.Russ*|Spain и индексы, многократно ускоряющие поиск.
Для удобной работы есть ряд функций: проверка глубины, проверка вхождения в заданное дерево, поиск последнего общего предка:
# select lca('1.2.2.3','1.2.3.4.5.6');
lca
-----
1.2
и т.п.
Не буду здесь грузить - все очень подробно расписано по ссылке.
Для PostgreSQL есть модуль ltree: http://www.sai.msu.su/~megera/postgres/gist/ltree/
Реализует организацию строк в деревья, структура пути похожа: Top.Countries.Europe.Russia.
Для выборки элементов можно использовать хитрые запросы типа Top.*{0,2}.sport*@.!football|tennis.Russ*|Spain и индексы, многократно ускоряющие поиск.
Для удобной работы есть ряд функций: проверка глубины, проверка вхождения в заданное дерево, поиск последнего общего предка:
# select lca('1.2.2.3','1.2.3.4.5.6');
lca
-----
1.2
и т.п.
Не буду здесь грузить - все очень подробно расписано по ссылке.
кстати, описанный выше способ работает и с дробными и с отрицательными индексами :)
например можно воткнуть /1/0.5/1/ или /1/1/-1/
такая фича позволяет неограниченно втыкать элементы куда угодно не ограничиваясь множеством натуральных чисел
например можно воткнуть /1/0.5/1/ или /1/1/-1/
такая фича позволяет неограниченно втыкать элементы куда угодно не ограничиваясь множеством натуральных чисел
А кто сказал про числа? :)
Просто скорее всего это будет использоваться с числами - по старинке как набор id-шников.
А чуть выше есть пример удобночитаемой иерархии для географических данных: Top.Countries.Europe.Russia - это пример реального дерева. Ограничения такие: на элемент не больше 255 символов, на всю цепочку - 64К (как показывает практика DMOZ-у даже для самых глубоких категорий достаточно 2К).
>такая фича позволяет неограниченно втыкать элементы куда угодно не ограничиваясь множеством натуральных чисел
не очень понял, что вы имели ввиду.
Просто скорее всего это будет использоваться с числами - по старинке как набор id-шников.
А чуть выше есть пример удобночитаемой иерархии для географических данных: Top.Countries.Europe.Russia - это пример реального дерева. Ограничения такие: на элемент не больше 255 символов, на всю цепочку - 64К (как показывает практика DMOZ-у даже для самых глубоких категорий достаточно 2К).
>такая фича позволяет неограниченно втыкать элементы куда угодно не ограничиваясь множеством натуральных чисел
не очень понял, что вы имели ввиду.
очень интересно, а можно ли получить поддерево «Васечкин-Круглов-Квадратов» без применения рекурсии?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MS SQL: hierarchyid — иерархия по-новому