Цитата:
А это надо?
Прежде чем трясти стоит таки немножко подумать, поэкспериментировать...
Как по вашему, =A=L=X=, каков план построит SQL для такого запроса?
Является ли план оптимальным?
Как вы думаете как будет SQL сервер выполнять n внешних соединений?
Можно ли ваш запрос сделать таким образом, чтобы он выполнялся оптимально?
Если приглядеться чуть чуть то очевидно что предлагаемый запрос почти аналогичен следующему:
select countries
outer join cities where cities.countryId == countries.Id
outer join streets where streets.cityId == cityId
...
(короче говоря ваш пример
)
...особенно, если таблицу Classif проиндексировать по полю level - этим можно будет пользоваться для index hint-а, "разделяющего" города от улиц, а следовательно хороший построитель планов запросов поведет себя почти так же, как в вышеприведенном фрагменте.
Конечно выполнятся такой запрос будет несколько медленне чем в случае с разделенными таблицами - как раз затраты на то чтобы отсеивать записи по этому индексу, зато преимущества очевидны - гибкость и универсальность, немыслимая в случае разделенных таблиц, а оно того стоит, когда речь идет о "нормализованном" классификаторе.
(Времени проводить сравнительные тесты сейчас просто нет, но тема для меня интересна, возможно когда нибудь займусь этим.)
Особенно удобно становится работать с таблицей подобным образом, если ограничивать уровень вложенности справочников (совсем как в 1С) - все накладные расходы очевидны плюс исключается случай, когда из-за одной, очень глубокой ветки запрос на все остальные непомерно раздувается лишними полями в строках, хотя их уровень вложенности мал по сравнению с ней. (Кстати, загоняя поле level в фильтр датасоурсов для такого случая с ограниченной глубиной, мы можем выстраивать такие же формы с "межклассовыми иерархиями" как в вашем примере, почти без единой строчки кода)
Цитата:
И только после ответа на эти вопросы можно вернутся к вашему - должна ли Аксапта делать такие запросы
Не утверждаю что обязана, но утвержаю что нет в этих запросах ничего страшного.
Насчёт вашей последней статьи.
Мне собственно непонятно в чём её соль - ведь в ней рассмотрен тривиальный случай межклассовой иерархии отношения один-ко-многим, в коей завязаны 99% всех таблиц в Аксапте и которой в общем то все просто обязаны уметь пользоваться. Отношения между странами-городами-улицами это просто классика жанра реляционных БД.
Тут видимо предлагается иерархии упорядочивать таким образом - разбивая их на набор взаимосвязанных таблиц. Действительно многие вещи можно уложить в такую схему (та же ассортиментная классификая товаров вполне может быть разбита на несколько таблиц по уровням классификации). Правда кроме преимуществ простоты подхода недостатков КУЧА:
- Жесткая привязка к определенной глубине иерархии - добавление новых уровней превращается в головняки программисту + сопутствующие проблемы
- Неоднородность построения запросов, а следовательно неоднородность кода, работающего с универсальным представлением дерева в TreeView
- Трудности с привязыванием подчиненных классификатору таблиц к разным его уровням
- Невозможность/чрезвычайная затрудненность переноса элементов с уровня на уровень
и т.д.
(вообще в идеале подход id/ParentId, level может обеспечить приличную универсальность, а если в системе есть возможность строить динамические запросы по вышеобозначенной схеме, то и нормальную производительность, сравнимую с разделением таблиц, особенно при ограниченном уровне вложенности)
...
И самое главное - если вы реализовали такой подход и не испытали ни одной из вышеперечисленных трудностей, то значит... вы имеете дело с простыми межклассовыми иерархиями отношений один-ко-многим, так что не морочьте мне голову и не пишите гневных опровержений не по адресу.
