Я создал эту тему, чтобы научиться делать "невозможное" - передать в представление параметр.

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

Теперь вместо длинного и некрасивого обращения к представлению, которое повторяется во многих местах и также требует правки при добавлении нового типа в параметре поиска



У меня получилось коротко и элегантно, все сложности бизнес-связок между разными таблицами документами спрятана в представлении. Я не показал команду сортировки, для простоты чтения.




В понедельник популяризую это представление, теперь навигация по сложной иерархии документов стала тривиальной: "спроси вьюху".

Надо хорошее имя для этой вьюхи придумать. KUCHA_MALA_V? DOCUMAP_V? NAVIDOC_V?

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

Я хочу эту мысль перевернуть. Мне кажется, что создание такого запроса - это наоборот, очень полезное упражнение (даже если запрос крайне неэффективен и не может использоваться в боевом коде)

Такой запрос собственно содержит ДНК и карту всей бизнес-системы для понимания и анализа.

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

Подкину идею на работе, написать такой убер-запрос. Костяк я уже сделал, осталось обернуть вокруг него оставшуюся сотню таблиц и вьюх.

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

Лол, я теперь знаю как это представление назвать.

BUSINESS_DNA

Оптимизатор не умеет оптимизировать сквозь функцию, поэтому вью предпочтительнее.

Сравните:

Select col1 from table(func(3))

Против

Select col1 from VIEW_V where col2 = 3

В первом случае табличная функция посчитает все колонки, и все кроме одной будут выкинуты.

Во втором, ненужные колонки даже не считаются.

"Бессвязная каша с дублями" называется табличное представление графа. Повторение ожидается для всех узлов кроме листьев. Это свойство такого преобразования.

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

(Если граф напрягает, думайте про дерево)

booby,


Ваше возмущение одинаково применимо к мировому атласу.

"Тут все собрано в одном месте, трудно понимать" "надо по кусочкам".

У меня новая цель - создать карту мира для чтения, понимания и тестирования.

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

Мой запрос может оказаться сложный и не быстрый, но функции мастер-карты он будет выполнять хорошо, я надеюсь.

А для вас у меня вопрос: где вы держите схему взаимосвязей всех таблиц и представлений системы?
- в визио чертеже архитектуры, безнадежно устаревшем?
- в голове?
- каждый раз смотрите в разные места в коде, чтобы вспомнить?

Если у вас появился новый коллега, как вы но ожидаете в структуре связок разобраться? Я своему покажу эту самую карту мира на две страницы, с секциями и комментариями.

Догадывался о существовании таких тулз, но не видел и не пользовался.
Совершенно естественно что "в нормальных конторах" составление и обновление модели делают люди (DBA & DA), которые в теме пока не отметились, или я не заметил. В нормальных конторах также наверное есть тестеры, тест менеджеры и тест планы. Я много работал в таких "нормальных конторах" где процесс накатан, и на каждую задачу уже есть и роль, и человек.

Сейчас у меня ситуация иная, где процесса нет, модели нет, и все мои хотелки придется реализовывать самому, не обладая знаниями ДБА (с БА у меня в порядке).

Кто-то видел, как выгладит модель простой схемы? Можете показать?

Такое было бы просто замечательно. Можно имена одного-двух таких инструментов, совместимых с Ораклом?

У меня в схеме около 400 таблиц и представлений. Я пока еще не знаю всех деталей их взаимодействия,
и у меня нет гарантий что во фрагменте кода, где я смотрю их связку между собой, не содержится ошибка.
Поэтому если нужно узнать достоверно, обычно смотрю код в трех разных местах. Пока все совпадало, что радует.

Промежуточный итог:
- над SY есть ДБА/прочие, контролирующие архитектуру схемы. Все изменения идут через них, и у них всегда можно получить правдивую модель схемы.
- Правильный Вася знает про существование автоматических инструментов. Непонятно, пользовался ли.
- у booby нет модели, но он может прочитать код и посмотреть как таблицы взаимодействуют, если возник вопрос. Как справляются другие члены его команды, непонятно.
- неофит тоже читает код (т.к. в компании нет архитекторов и детальной документации), и одновременно составляет модель схемы в форме SQL запроса; такой подход вызывает общее негодование.

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

View позволяет вычислять только то, что нужно запросу. Табличная функция будет вычислять все, т.к. не знает что нужно, а что нет.

А почему вы сами так не делаете?

Я не подозревал, что вы вместе работаете..