Здравствуйте.
Откуда подчерпнуть информацию о паттернах проектирования БД?

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

Вот, только увидел, в соседнем топике краем коснулись этой проблемы, но в другой плоскости. Так что идея витает в воздухе, постепенно оформляясь ;)

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

Это только пример как паттерн может выглядеть. Это типовое решение, оно имеет свои недостатки и достоинства, область применения. Просмотрите книгу GoF по паттернам проектирования для ООП. Там все так по каждому паттерну и расписано: идея, в схематичном виде, область применения, ее достоинства и недостатки.

Настоятельно напоминаю: вопрос не о деревьях (я начинаю жалеть, что вообще их коснулся), вопрос о паттернах проектирования баз данных.

Или никто вообще ничего не слышал о систематизированной подборке?

Genady
Не понял почему последовало столько эмоций на мое небольшое замечание. :)
Что касается патернов для БД, то не представляю себе каими они могут быть.
Могу только предположить почему их нет. Например потому, что реляционная теория достаточно формализована, чтобы можно было проверять свои решения а не ориентироваться на народный опыт.

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

Какими могут быть паттерны я вроде бы показал. Есть типовая задача - разместить древовидную структуру данных в плоской таблице. Есть неплохое решение, которое можно считать типовым. Кстати вставка-удаление в данную структуру тоже достаточно проста - если я правильно помню (я дела эти системы три года назад) после вставки-удаления узла происходит модификация одним update запросом.Человек, который не знает этого типового решения, городит примерно такое безобразие в виде сохранения в текстовом поле id предков записи разделенных точками. И синтаксический разбор этих полей при посторении дерева. А уж о трудоемкости вставки-удаления я не говорю вообще. Какое отношение ТАКОЕ решение имеет к степени формализации реляционной теории?

Denis Popov
У меня в закладках есть Library of Free Data Models, но, честно говоря, самому воспользоваться пока не привелось. И скорее всего это не шаблоны, а просто набор реализаций.
Да, это примеры реализаций. Я даже диаграмку игры Shrek2 нашел.


Andres 1
На домашней странице Richard T. Snodgrass в PDF доступна полная версия его книги "Developing Time-Oriented Database Applications in SQL" (с примерами).

Спасибо за ссылку, скачаю, посмотрю.

Andres 1На домашней странице Richard T. Snodgrass в PDF доступна полная версия его книги "Developing Time-Oriented Database Applications in SQL" (с примерами).

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

Искал в сети эту книгу , она, как мне кажется, наиболее интересна в данном контексте, но ее, похоже, нет нигде в электронном виде. Нашел книгу того же John Celko по деревьям и иерархическим структурам, но это не совсем то, что нужно.

Genady
Не совсем так Вот здесь например перевод статьи обратите внимание на процедуры модификации, просто множества приходится постоянно перетряхивать при модификациях.

Вот и перевод статьи нашелся. Большое Спасибо!
На самом деле там все не так сложно - самый большой и сложный код в статье, это код сжатия разрежений в значениях id левых и правых сторон записей при удалении поддеревьев/узлов. Я вообще этим не занимался. Жизнь разработчика сильно упрощает условие, что одновременно добавляется/удаляется только один узел дерева. Тогда процедура вставки/удаления влечет за собой только модификацию левосторонних и правостороних id путем увеличения/уменьшения их на 1. Это делается одним update запросом. Максимиум что ему может понадобитться сделать это инкрементировать/декрементировать во всех записях таблицы (это случай удаления самого правого листа дерева) значения двух целочисленных полей.
IMHO сжатие разрежений нужно только для сохранения читабельности таблицы, на работе оно никак не отражатеся.

Andres 1
Ну да. И хорошо. Так и должно быть для топика "паттерны".
Я на sql.ru не очень давно, но разве не возникают регулярно вопросы типа "Помогите изменить одним запросом мою базу, чтобы была с логом версий, с учетным временем, etc etc, используя не более одного поля DATETIME на таблицу и чтобы мне не нужно было переделывать клиента"
С этой точки зрения я как-то на книгу не посмотрел. Сейчас посмотрю повнимательней - все-таки книга на 500 листов, я ее "по диагонали" просмотрел, сейчас почитаю с большим интересом.

Genady
Ну что ж, хотите паттернов с иерархиями?Нате. :)

Не понравилось, давайте еще ;). Во первых, обсуждается давний прием с внутренними ссылками, во вторых, все явно заточное под SQL Server2000 и никаких попыток выработать более универсальное решение нет. Ну и хранимые процедуры там, где можно (при другом решении таблиц) в принципе обойтись чистым SQL. Что понравилось - вынести различные по связям типы деервьев над одинаковыми данными в различные таблицы. Надо будет запомнить. Все равно спасибо, это уже "горячее".

Сахават Юсифов
А чем Вам не нравится :

1. Отец
2. Сын
3. ...

Обыкновенная таблица. Универсальная, с любой глубиной.
Люди! Мне очень не охота флеймить по поводу различных представлений иерархий в плоских таблицах, я об этом уже давно думал и свои выводы сделал. Мне это уже не интересно. Я о паттернах проектирования поговорить зашел. В общем-то разговора на заданную тему пока не получается, но чтобы не давать опускаться топику в списке свежих сообщений приходится следовать интересам посетителей ;).

Основное отличие данного решения от того, что придумал Селко в том, что Селко изобрел метод преобразования иерархии во вложенные множества (nested sets). Что это дает? SQL это язык, ориентированный на работу с множествами. Технически преборазование реализовано путем введения ЦЕЛОЧИСЛЕННЫХ УНИКАЛЬНЫХ полей. Следовательно, мы можем
1) В рамках SQL получить выборку практически любой сложности, под любую типовую задачу работы с иерархиями.
2) Получить выборку быстро (если создадим индексы по данным полям).

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