powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Представление иерархии
58 сообщений из 58, показаны все 3 страниц
Представление иерархии
    #40013639
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый вечер,

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

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
  select ..
    from ORDERS o
    left join ORDERS_JOBS oj on o.doc_id = oj.order_id   -- orders-activities link table, N:M
         join SPELUNKING  s  on oj.doc_id = s.doc_id     
         join WATERSKIING w  on oj.doc_id = w.doc_id
         join CLIMBING    c  on oj.doc_id = c.doc_id
   where 
             :id = o.doc_id or
             :id = s.doc_id or
             :id = w.doc_id or
             :id = c.doc_id



Критерий поиска (where) срабатывает, т.к. doc_id разных типов документов имеют сплошную нумерацию.
При поиске фиксируется один документ поиска, и находятся все сопутствующие документы других типов графа.

Тут бы пригодились параметризованные представления, но Оракл таких пока не придумал, поэтому придется без них.

Можно в представление поместить все до "where", и тогда в каждом запросе придется добавлять это многострочье, которое со временем будет расти.

Эмуляции параметризованного представления через глобальную переменную или таблицо-функцию не устраивают.

А можно как-то в представление засунуть список поисковых полей? Что-то вроде такого:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
CREATE VIEW DOCUPILE_V
  select ..
         (o.doc_id, s.doc_id, w.doc_id, c.doc_id) as SearchList
    from ORDERS o
    left join ORDERS_JOBS oj on o.doc_id = oj.order_id   -- orders-activities link table, N:M
         join SPELUNKING  s  on oj.doc_id = s.doc_id     
         join WATERSKIING w  on oj.doc_id = w.doc_id
         join CLIMBING    c  on oj.doc_id = c.doc_id;

...

  select * from DOCUPILE_V where :id in (SearchList)  -- цель - свернуть многострочье поиска.
...
Рейтинг: 0 / 0
Представление иерархии
    #40013641
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Померял время исполнения; этот многострочник учетверяет время запроса до секунды-двух, т.к. оптимизатор не знает что они взаимоисключающие.

вместо

Код: plsql
1.
2.
3.
4.
5.
   where 
             :id = o.doc_id or
             :id = s.doc_id or
             :id = w.doc_id or
             :id = c.doc_id



будет значительно быстрее определить тип дока по :id, а затем свернуть до одного условия поиска.
Если бы у графа был корень он был бы дедушкой, можно было бы свести к корню, и строить иерархию от него.
...
Рейтинг: 0 / 0
Представление иерархии
    #40013643
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А ты уверен, что правильно понимаешь как работает конструкция
Код: plsql
1.
2.
3.
4.
5.
6.
  select ..
    from ORDERS o
    left join ORDERS_JOBS oj on o.doc_id = oj.order_id   -- orders-activities link table, N:M
         join SPELUNKING  s  on oj.doc_id = s.doc_id     
         join WATERSKIING w  on oj.doc_id = w.doc_id
         join CLIMBING    c  on oj.doc_id = c.doc_id
...
Рейтинг: 0 / 0
Представление иерархии
    #40013644
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вячеслав Любомудров
А ты уверен, что правильно понимаешь как работает конструкция
Код: plsql
1.
2.
3.
4.
5.
6.
  select ..
    from ORDERS o
    left join ORDERS_JOBS oj on o.doc_id = oj.order_id   -- orders-activities link table, N:M
         join SPELUNKING  s  on oj.doc_id = s.doc_id     
         join WATERSKIING w  on oj.doc_id = w.doc_id
         join CLIMBING    c  on oj.doc_id = c.doc_id



Вроде бы да, я не задумывался особо когда писал.
А что, какая-то часть показалась необычной?

Orders-jobs содержит две колонки. В первой (order_id) всегда id заказа, во второй всегда id документа который не заказ, но с заказом связан. Не для всех заказов есть строка в этой таблице. PK = (order_id,doc_id).
...
Рейтинг: 0 / 0
Представление иерархии
    #40013645
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот и надо это всегда/невсегда правильно оформлять
И, возможно, юзать скобки -- пока оно выполняется последовательно и видеть INNER JOIN после OUTER JOIN без изменения порядка скобками часто похоже на ошибку
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
tst> create table t1 as select 1 id from dual;

Table created.

tst> create table t2 as select 1 id, 1 oid from dual;

Table created.

tst> create table t3 as select 3 id from dual;

Table created.

tst> create table t4 as select 1 id from dual;

Table created.

tst> select * from t1 left join t2 on t1.id=t2.oid;

        ID         ID        OID
---------- ---------- ----------
         1          1          1

1 row selected.

tst> select * from t1 left join t2 on t1.id=t2.oid join t3 on t2.id=t3.id;

no rows selected

tst> select * from t1 left join t2 on t1.id=t2.oid join t3 on t2.id=t3.id join t4 on t2.id=t4.id;

no rows selected

tst> select * from t1 left join t2 on t1.id=t2.oid LEFT join t3 on t2.id=t3.id;

        ID         ID        OID         ID
---------- ---------- ---------- ----------
         1          1          1

1 row selected.

tst> 

Ты ожидал именно такого результата?
...
Рейтинг: 0 / 0
Представление иерархии
    #40013646
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вячеслав Любомудров,


Вы правы, пример жёлтым скроет заказ, у заказа есть активности, но только типов не включенных в запрос (напр, только акваланг, которого в запросе нет).

Левый джойн приносит много разных типов документов (в примере-занятий). В более общем случае пример иерархии такой:

Код: plaintext
1.
2.
3.
4.
5.
    Заказ1       Заказ2
     |         /    |    \
     |        /     |     \
     |       /      |      \
     |      /       |       \
       Пещеры     Лыжи      Акваланг

Если заказ одинокий (не имеет подчинённых документов, то его все равно нужно показать, хотя строки в связке нет. Исходя из этого я сделал левый джойн.
Среди всех занятий в бд меня интересуют не все,поэтому я использовал внутренний джойн чтобы исключить ненужные. А если все - ненужные, то пропадает сам заказ.

Проблема.

Если я сначала сделаю inner join таблицы связок с активностями, а потом outer с заказами, то должно быть правильно. Вот только как это делать скобками я не знаю, знаю через вложенный селект.

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
select ..
    from ORDERS o
    left join 
         (select ... , oj.order_id
            from ORDERS_JOBS oj
             join SPELUNKING  s  on oj.doc_id = s.doc_id     
             join WATERSKIING w  on oj.doc_id = w.doc_id
             join CLIMBING    c  on oj.doc_id = c.doc_id) a
                   on o.doc_id = a.order_id
 
...
Рейтинг: 0 / 0
Представление иерархии
    #40013647
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я не разработчик и что-то советовать именно по алгоритму вряд ли смогу (лениво)
Но вот употреблять правильную терминологию посоветовать могу -- иерархия -- эьто таки [практически однокорневое] дерево с более чем одним уровнем наследования
Это использование специальных "иеархических" запросов, использующих, как правило, классический CONNECT BY или новомодный
Recursive Subquery Factoring (через with)
А у тебя, насколько я могу навскидку увидеть -- сплошной OUTER JOIN, только надо правильно расставить приоритеты -- кто однозначно есть, а кого может и не быть
...
Рейтинг: 0 / 0
Представление иерархии
    #40013648
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Код: plsql
1.
2.
3.
4.
5.
tst> select * from t1 left join t2 on t1.id=t2.oid LEFT join t3 on t2.id=t3.id;

        ID         ID        OID         ID
---------- ---------- ---------- ----------
         1          1          1



Такой вариант не устраивает, т.к. добавляет лишние строки в мой отчёт. Поскольку заказы наверху иерархии (создаются первыми), и должны всегда быть показаны, я думаю нужно к ним делать left join всей остальной иерархии,и больше ничего что могло бы спрятать строчку
...
Рейтинг: 0 / 0
Представление иерархии
    #40013649
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Перестаем называть член пиписькой и начинаем лечить сифилис (с)
...
Рейтинг: 0 / 0
Представление иерархии
    #40013651
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вячеслав Любомудров
Я не разработчик и что-то советовать именно по алгоритму вряд ли смогу (лениво)
Но вот употреблять правильную терминологию посоветовать могу -- иерархия -- эьто таки [практически однокорневое] дерево с более чем одним уровнем наследования
Это использование специальных "иеархических" запросов, использующих, как правило, классический CONNECT BY или новомодный
Recursive Subquery Factoring (через with)
А у тебя, насколько я могу навскидку увидеть -- сплошной OUTER JOIN, только надо правильно расставить приоритеты -- кто однозначно есть, а кого может и не быть


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

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

Однозначно есть только верхний уровень. Второй показан в примере,и вроде разобрались. Ещё могут дочерние уровни от активностей и от связок, там получится outer join для прямых наследников,или ещё одна вложенная конструкция для наследников через таблицы связки.

Плюс есть полно мест в этом запросе где просятся inner join т.к. присутствие значений гарантируется внешними ключами.

В связи с этим вопрос: если ссылочная целостность обеспечивает одинаковый результат для inner и outer, есть ли предпочтение?помню что в синхронных мат представлениях есть предпочтение в пользу inner, про другие ситуации не знаю.
...
Рейтинг: 0 / 0
Представление иерархии
    #40013652
Alibek B
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
with params as (select sysdate as clock, ... from dual)
, search as (select 0 as id from dual where 0=1
union all select :id1 from dual where :id1 is not null
union all select :id2 from dual where :id2 is not null
...
)
, ids as (select distinct id from DOCUPILE_V where doc_id in (select id from search))
select ...
from params
join ids on (id is not null)
...
...
Рейтинг: 0 / 0
Представление иерархии
    #40013653
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Alibek B.
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
with params as (select sysdate as clock, ... from dual)
, search as (select 0 as id from dual where 0=1
union all select :id1 from dual where :id1 is not null
union all select :id2 from dual where :id2 is not null
...
)
, ids as (select distinct id from DOCUPILE_V where doc_id in (select id from search))
select ...
from params
join ids on (id is not null)
...



Спасибо, я с утра прочитаю и испробую.
...
Рейтинг: 0 / 0
Представление иерархии
    #40013818
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Утро вечера явно мудренее. Весь сыр-бор с левым джойном к заказам помогал предохранить одинокие заказы, которые не участвовали ни в одной из таблиц связок. Вместо того чтобы их пытаться предохранить усложненными запросами, почему их просто не добавить в конце, раз они такие особые?

Вместо начального плана (с ошибкой, указанной Вячеславом)
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
select ..
    from ORDERS o
    left join ORDERS_JOBS oj on o.doc_id = oj.order_id   -- orders-activities link table, N:M
         join SPELUNKING  s  on oj.doc_id = s.doc_id     
         join WATERSKIING w  on oj.doc_id = w.doc_id
         join CLIMBING    c  on oj.doc_id = c.doc_id
   where 
             :id = o.doc_id or
             :id = s.doc_id or
             :id = w.doc_id or
             :id = c.doc_id



Сделать

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
select ..
  from ORDERS_JOBS oj -- orders-activities link table, N:M
  join SPELUNKING  s  on oj.doc_id = s.doc_id     
  join WATERSKIING w  on oj.doc_id = w.doc_id
  join CLIMBING    c  on oj.doc_id = c.doc_id
  right outer join ORDERS  o on oj.order_id = o.doc_id 
 where 
        :id = o.doc_id or
        :id = s.doc_id or
        :id = w.doc_id or
        :id = c.doc_id



Основная идея - вместо того, чтобы начинать с вершины иерархии и сохранять ветки без листьев от пропажи,
строить снизу, наслаивая ветки внешними джойнами. Вне SQL, обработка дерева снизу вверх редко практикуется (построение дерева Хоффмана - единственное где такое припоминаю), я даже не подумал что так можно было сделать.
...
Рейтинг: 0 / 0
Представление иерархии
    #40013824
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Alibek B.,

я только сейчас заметил что код использует несколько :id1, id2, ...

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

Похоже, я выкрутился, "передав" параметр в представление, добавив колонку всех возможных значений :id.

Теперь вместо
Код: plsql
1.
2.
3.
4.
5.
6.
select * from DOCUPILE_V t
 where 
             :id = t.idOrder or
             :id = t.idSpelunk or
             :id = t.idWaterSki or
             :id = t.idClimbing


я пишу

Код: plsql
1.
select * from DOCUPILE_V t  where :id = t.idSearch
...
Рейтинг: 0 / 0
Представление иерархии
    #40013829
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
...
Рейтинг: 0 / 0
Представление иерархии
    #40013854
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Я читаю, что параметризованные представления - самая затребованая фича для Оракла, но так пока и не сделана.

Учитывая, что эту фичу можно без великого труда сделать через глобальные переменные, есть ли причины которые не позволяют Ораклу выбрать синтакс и соорудить такую штуку?

Табличные функции или курсоры с параметром это все же не совсем то.
...
Рейтинг: 0 / 0
Представление иерархии
    #40013872
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plsql
1.
2.
3.
4.
             ...   ORDERS_JOBS oj on o.doc_id = oj.order_id   -- orders-activities link table, N:M
         join SPELUNKING  s  on oj.doc_id = s.doc_id     
         join WATERSKIING w  on oj.doc_id = w.doc_id
         join CLIMBING    c  on oj.doc_id = c.doc_id


1)
Здесь могло бы быть полезным, если бы ORDERS_JOBS "знал", где искать детали,
что-то вроде:

Код: plsql
1.
2.
3.
4.
             ...   ORDERS_JOBS oj on o.doc_id = oj.order_id   -- orders-activities link table, N:M
         join SPELUNKING  s  on oj.doc_id = s.doc_id  And oj.dest = 's'   
         join WATERSKIING w  on oj.doc_id = w.doc_id And oj.dest = 'w'   
         join CLIMBING    c  on oj.doc_id = c.doc_id And oj.dest = 'c'   



2) поищи по форуму "секционирование для бедных" и ознакомьтесь с "partitioned view"
где-то здесь:
https://docs.oracle.com/cd/A57673_01/DOC/server/doc/A48506/partview.htm

оно для похожих на ваш случай историй хорошо подходит.
...
Рейтинг: 0 / 0
Представление иерархии
    #40013875
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
booby,

Спасибо за комментарий.

1) doc_id индексирования во всех таблицах, и джойны выглядят довольно эффективно в плане. Таблицы s,w,c являются вью-расширениями одной таблицы DOCS, поэтому это все эффективно идентичные селф-джойны с фильтрацией по полю типа.
Т.е.

Код: plsql
1.
2.
3.
4.
...   ORDERS_JOBS oj on o.doc_id = oj.order_id
         join DOCS s  on oj.doc_id = s.doc_id and s.type='s'
         join DOCS w  on oj.doc_id = w.doc_id and w.type='w'
         join DOCS c  on oj.doc_id = c.doc_id and c.type='s'



Но я понял общую идею, что каждый из джойнов был бы короче, и быстрее.

В фильтре where, я думал что можно ускорить поиск, вычислив единожды тип параметра, и не делая лишние сравнения "or". Попробовал, та же скорость и практически тот же план, по той же причине что выше.

Сейчас запрос исполняется за 0.1-0.2 секунды,и отчёт выскакивает за секунду, что возможно даже слишком быстро - почти не виден красивый прогресс бар.

2) я почитал про partitioning, эт все же для баз данн на пару порядков превышающих мою. У нас все таблицы заметно меньше миллиона строк, и большинство меньше десяти колонок. Но сколько связок!
Простой запрос может использовать 20-30 джойнов, если считать скрытые. Структура данных в виде сложного графа представленная в табличном виде это интересно.
Например, нашел несколько вспомогательных связующих таблиц которые расширяют основные связующие таблицы.
И любопытно что тот, кто это все написал не забыл везде проставить составные внешние ключи.

Ковыряться в таком коде - как кроссворды решать. Со временем все сходится и наступает иллюзия полного понимания.
...
Рейтинг: 0 / 0
Представление иерархии
    #40013878
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL,

Похоже, вы опять не поняли.
Дело не в количестве строчек, а в способе смотреть на них

вам, почти наверно, не нужен и, почти наверно вреден
Код: plsql
1.
2.
3.
4.
             ...   ORDERS_JOBS oj on o.doc_id = oj.order_id   -- orders-activities link table, N:M
         join SPELUNKING  s  on oj.doc_id = s.doc_id  And oj.dest = 's'   
         join WATERSKIING w  on oj.doc_id = w.doc_id And oj.dest = 'w'   
         join CLIMBING    c  on oj.doc_id = c.doc_id And oj.dest = 'c'   



Нужен вам
Код: plsql
1.
2.
3.
4.
5.
             ...   ORDERS_JOBS oj    join SPELUNKING  s  on oj.doc_id = s.doc_id  And oj.dest = 's'   
union all
          ...   ORDERS_JOBS oj  join WATERSKIING w  on oj.doc_id = w.doc_id And oj.dest = 'w'   
union all
        ...   ORDERS_JOBS oj  join CLIMBING    c  on oj.doc_id = c.doc_id And oj.dest = 'c'   


с соответствующим случаю оформленным списком выбора.
и, скорее всего, она у вас уже есть, просто вы её "не увидели".
...
Рейтинг: 0 / 0
Представление иерархии
    #40013883
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
booby,

Union в одну колонку мне не подходит по нескольким причинам,
- вьюхи активностей разные
- заказчик их хочет видеть на одной строчке в отчёте
- к каждому типу активности привязаны свои подчиненные таблицы и операции
- union у меня уже есть, в виде правой колонки ORDERS_JOBS

Этот запрос (теперь уже представление) является костяком для нескольких отчётов, и многих будущих.

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

В моей бд есть крепкозапутанные зависимости между документами разного типа. Вместо того чтобы для каждой новой задачи чесать репу и вспоминать как прыгнуть от акваланга к Пете, или от Маши к ледорубу, я решил один раз написать универсальное представление которому даёшь один документ, и он притаскивает все зависимые сверху, снизу и сбоку. Где нужно, вернуть несколько строчек. Начиналась как функция (старые привычки быстро не умирают) но переделал на sql.

Теперь я просто пишу

select * from DOCSPILE_V where Document = :id

Вьюха сама определяет тип переданного объекта, и достраивает все сопутствующие.
Например, если :id это Петя, добавит его заказы, статус заказов, инвойсы и статус оплаты.

Если :id это заказ, то вытащит клиентов (Вася и маша заказывали вместе), инвойс этого заказа и т.д.

Если :id это инвойс, то вытащит заказ(ы) и занятия связанные с этим инвойсом, также имена людей фигурирующих в заказе/заказах.

Вьюха гарантирует присутствие в отчёте как минимум одной строки, если ей передают существующий :id любого типа.
Т.е. если Вася есть в системе, но ничего не заказывал, то вызов представления с :id Васи даст одну строку. Вася будет упомянут, но все другие колонки будут пустые.

А вот у заказа будет минимум две заполненных колонки (нужен Гена, чтоб заказ сделать). У инвойса - ещё больше, т.к. ему предшествует создание других документов.

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

Слово "параметр" используется вольно. Представления в Оракле не умеют принимать параметры, но для моего узкого случая конечного числа параметров у меня получилось это сделать без внешних переменных.
...
Рейтинг: 0 / 0
Представление иерархии
    #40013913
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1. При работе со сквозным идентификатором поддержу booby - вариант union ALL c последующей группировкой часто более выгоден, нежели чем хитровыписанный join.
2. В означенной ситуации напрасно отказались от варианта с функцией. Конкретно - от варианта pipelined function, который с точки зрения интерфейса суть искомое параметризованное представление.
...
Рейтинг: 0 / 0
Представление иерархии
    #40013974
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL,

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

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

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

Главное в гармони не клавиши, а меха. Их сжимать и разжимать надо, чтобы музыка играла.
Так, например, бывают устроены политические системы, пар в которых надо периодически сжимать и разжимать, чтобы музыка государственности играла без долговременного затихания.

Oracle, это не гармонь, и даже не орган - у органа один конец трубы свободно открытый.
Oracle - это сверхдлинный блок цилиндров, в которых находится пар, сверху закрытый поршнями,
и удерживаются они только вашей личной силой. А расширяться этот пар в объеме легко может на 4-5 порядков.

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

Мораль из этого такая:
- не стремитесь к ширизне и универсальности интерфейсов.
- читайте andrey_anonymous и думайте над тем, что он пишет.

И да, поджать парок на 4-5 порядков - это больше для показательного кино на ютубе,
но в диапазоне от .75 до 7500 - это совершенно обыденные рабочие варианты на рутинной основе.
К этому тоже надо быть морально готовым.

Конечно можно и так - сначала написать именно ваш джойн, а потом разложить его на union all, и доложить о достигнутых результатах.
Но со временем, в норме, это должно становиться скучным.
...
Рейтинг: 0 / 0
Представление иерархии
    #40013991
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
andrey_anonymous
1. При работе со сквозным идентификатором поддержу booby - вариант union ALL c последующей группировкой часто более выгоден, нежели чем хитровыписанный join.
2. В означенной ситуации напрасно отказались от варианта с функцией. Конкретно - от варианта pipelined function, который с точки зрения интерфейса суть искомое параметризованное представление.


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

Согласен что функцию было бы намного легче писать,да и читать. Функция (пайплайн) была на 80% закончена, когда я заметил что у меня всего два if, и я не полагаюсь на библиотечные функции. Поскольку функции я писать умею, а сложные (не то же самое что длинные) запросы в SQL это для меня редкая возможность, я переделал на SQL.

В моем случае, функция эффективно может заменить SQL, т.к.результат содержит от десятка до сотни строк для любого значения параметра. В более общем случае, функция является забором для оптимизатора.
...
Рейтинг: 0 / 0
Представление иерархии
    #40013999
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Снова бредовая постановка и бредовые выводы ... ты эту тему зачем создал?
...
Рейтинг: 0 / 0
Представление иерархии
    #40014004
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
booby,

Мне понравилась ваша аналогия с паровой машиной, но по прежнему непонятно желание использовать union.

Идея интерфейса который делает "все" меня не прельщает, это противоречит принципу strong cohesion, которому я стараюсь следовать. В то же время, я начал видеть появление запросов "найти все документы по клиенту", "найти все документы по заказу", "найти все документы по инвойсу" которые следовали похожей логике, но повторяли код.

Одно из качеств SQL, которое я не встречал в процедурных языках, это способность оптимизатора выкинуть неиспользуемый код следуя внешним фильтрам. Это как если бы функция возвращающая несколько значений заметила бы что я не использую второе и третье, и не стала бы их вычислять. Очень эффективно!

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

Задача: распечатать все натуральные числа меньше миллиона зная значение и позицию одной из цифр.
Параметры: цифра (0-9), ее позиция (0-5).
Числа должны следовать критериям:
- делиться на семь
- делиться на 13
- сумма цифр четная
- все цифры разные

Я знаю как такую задачку решить через джойны и фильтры, но не знаю, как тут применить юнион.
...
Рейтинг: 0 / 0
Представление иерархии
    #40014013
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
graycode
Снова бредовая постановка и бредовые выводы ... ты эту тему зачем создал?


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

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

Теперь вместо длинного и некрасивого обращения к представлению, которое повторяется во многих местах и также требует правки при добавлении нового типа в параметре поиска
Код: plsql
1.
2.
3.
4.
5.
 where 
             :id = idOrder or
             :id = idSpelunk or
             :id = idWaterSki or
             :id = idClimb



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

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
select * from DOCSPILE_V where idDocument = :id  -- выдать все документы связанные с :id (клиент, или заказ, или жалоба, или ...)
...
select distinct numOrder from DOCSPILE_V where idDocument = :idClient -- перечислить номера всех заказов клиента
...
select distinct numInvoice from DOCSPILE_V where idDocument = :idOrder -- перечислить номера всех инвойсов данного заказа
...
-- получить клиента по инвойсу, цепочка инвойс->исполнение->заказ->клиент известна представлению
-- у инвойса всегда ровно один клиент, поэтому тут просто.
select idClient into l_ClientId from DOCSPILE_V where idDocument = l_InvoiceId; 



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

Надо хорошее имя для этой вьюхи придумать. KUCHA_MALA_V? DOCUMAP_V? NAVIDOC_V?
...
Рейтинг: 0 / 0
Представление иерархии
    #40014017
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
НеофитSQL,

авторчтобы научиться делать "невозможное" - передать в представление параметр
В большинстве случаев это не требуется, кроме того Oracle умеет проваливать предикат внутрь представления, если возникла крайняя необходимость, то можно сделать так как рекомендовал andrey_anonymous, есть еще пара вариантов, о которых тебе лучше пока не знать))

В остальном твои сообщения бессвязный поток сознания, без структуры и примера данных вообще не имеющий смысла, очень похоже что архитектура трешовая, а то что ты поверх нее наваял еще трешовее.
...
Рейтинг: 0 / 0
Представление иерархии
    #40014021
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Было несколько комментариев, которые намекали что создание запроса, связывающего все основные таблицы бизнеса согласно их взаимоотношениям - это вредно.

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

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

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

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

Такой "эталон" скорее всего будет медленным, но зато позволит легко плодить юнит-тесты для быстрого боевого кода. Если результаты не совпали - у кого-то ошибка требующая исправления.
...
Рейтинг: 0 / 0
Представление иерархии
    #40014027
dmdmdm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL
Такой запрос собственно содержит ДНК


Да, для обучения сойдет.

В дальнейшей работе, если такой запрос встретится, будет естественная реакция "у тебя ошибка в ДНК".
...
Рейтинг: 0 / 0
Представление иерархии
    #40014034
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dmdmdm
НеофитSQL
Такой запрос собственно содержит ДНК


Да, для обучения сойдет.

В дальнейшей работе, если такой запрос встретится, будет естественная реакция "у тебя ошибка в ДНК".


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

BUSINESS_DNA
...
Рейтинг: 0 / 0
Представление иерархии
    #40014122
Фотография env
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL
создание такого запроса - это наоборот, очень полезное упражнение

Цель какая у этого упражнения? Получить бессвязную кашу с дублями всего на всё, ради устранения которых потом приходится наворачивать довольно дорогое устранение дублей?
...
Рейтинг: 0 / 0
Представление иерархии
    #40014259
PuM256
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
НеофитSQL

Тут бы пригодились параметризованные представления, но Оракл таких пока не придумал, поэтому придется без них.

Таки придумал - SQL_MACRO ( https://docs.oracle.com/en/database/oracle/oracle-database/20/lnpls/plsql-language-elements.html#GUID-292C3A17-2A4B-4EFB-AD38-68DF6380E5F7)
Эмуляции параметризованного представления через глобальную переменную или таблицо-функцию не устраивают.

Чем pipelined-функция не устраивает?
...
Рейтинг: 0 / 0
Представление иерархии
    #40014267
graycode
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
PuM256,

У него 11-я версия, но и для нее были решения, однако давать ему в руки их не стоит, по крайней мере сейчас))
...
Рейтинг: 0 / 0
Представление иерархии
    #40014303
Alibek B
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
booby
если собрать собрать все, что вы понаписали в топике, то получится, что вы работу нескольких различных задач хотите обеспечить единственным универсальным интерфейсом.

Да, похоже на то.
Когда я впервые столкнулся с СУБД, у меня тоже было подобное желание, затащить привычные (в прикладном программировании) подходы в SQL — универсальные параметрические запросы и представления, абстрактные функции, в которые передаются имена таблиц и столбцов.
В большинстве случаев в SQL это не нужно и даже явно противопоказано. В SQL длинная портянка запроса с повторяющимися фрагментами может быть эффективнее.
Не нужно библиотечные подходы тащить непосредственно в SQL. Их можно применять в серверном коде, но и то с учетом множества особенностей.
...
Рейтинг: 0 / 0
Представление иерархии
    #40014513
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
PuM256

Чем pipelined-функция не устраивает?


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

Сравните:

Select col1 from table(func(3))

Против

Select col1 from VIEW_V where col2 = 3

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

Во втором, ненужные колонки даже не считаются.
...
Рейтинг: 0 / 0
Представление иерархии
    #40014520
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
env
НеофитSQL
создание такого запроса - это наоборот, очень полезное упражнение

Цель какая у этого упражнения? Получить бессвязную кашу с дублями всего на всё, ради устранения которых потом приходится наворачивать довольно дорогое устранение дублей?


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

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

(Если граф напрягает, думайте про дерево)
...
Рейтинг: 0 / 0
Представление иерархии
    #40014533
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL
в отличие от кучи значений собранных по union
...
Рейтинг: 0 / 0
Представление иерархии
    #40014563
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL
...
Табличное представление графа, в отличие от кучи значений собранных по union...


мда...
Не важно, сколько вам лет.
В ребёнка вас превращает неостановимое желание использовать в речи слова, смысла которых вы не понимаете.
А ведь я почти поверил, читая 22224458 , что "наверно вы все сделали правильно" , и стер длинный пост про cohesion.

Кратко так: он у вас есть, только имени ему нет.
У вас спрут какой-то, а не cohesion, источник ошибок (это если вам не нравится термин "задвоение",
но, похоже, вы не понимаете, о чём речь) и гарант головной боли для следующего несчастного.

А необходимый вам atomic cohesion, по вашему рассказу судя, ничто лучше, чем union all не обеспечит.
Кроме того, он же, union all, почти автоматический, то есть - полуавтоматический,
гарант low coupling между серверной и клиентской частью кода.

Как-то так...
...
Рейтинг: 0 / 0
Представление иерархии
    #40014584
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
booby,


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

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

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

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

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

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

Если у вас появился новый коллега, как вы но ожидаете в структуре связок разобраться? Я своему покажу эту самую карту мира на две страницы, с секциями и комментариями.
...
Рейтинг: 0 / 0
Представление иерархии
    #40014590
Правильный Вася
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL
где вы держите схему взаимосвязей всех таблиц и представлений системы?

Для этого есть множество инструментов реверсивного вынимания схемы данных со всеми взаимосвязями и комментариями ко всем объектам и связям (если они прописаны в БД, в Оракле такое есть).
Т.е. это всегда актуально, именно в любой момент.

Кстати, если в твоей схеме 10 табличек для одного пользователя, то их можно и помнить :)
Реальные схемы содержат тысячи (а то и десятки тысяч) объектов схемы.
...
Рейтинг: 0 / 0
Представление иерархии
    #40014603
Фотография SY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL


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

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


Ты про data modeling tools что нибудь слышал? В нормальных конторах запрос на любые изменения (логические или физические) базы идут к data modeler (это может быть тот-же DBA) который вместе BA (business analyst) рассматривают запрос, отклоняют или утверждают (возможно с поправками) затем data modeler вносит изменения в model и генерирует DDL. И это не столько для базы сколько для бизнеса. Ведь это позволяет контролировать что тот-же самый business term всегда получает то-же имя поля во всех базах и если business term name or/and logic изменилась мы всегда знаем где менять.

SY.
...
Рейтинг: 0 / 0
Представление иерархии
    #40014618
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL
...
А для вас у меня вопрос: где вы держите схему взаимосвязей всех таблиц и представлений системы?
- в визио чертеже архитектуры, безнадежно устаревшем?
- в голове?
- каждый раз смотрите в разные места в коде, чтобы вспомнить?

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

НеофитSQL

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

Разрешите вы мне, или нет, но вот эту херню, я уже просто не буду комментировать...
...
Рейтинг: 0 / 0
Представление иерархии
    #40014648
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SY

Ты про data modeling tools что нибудь слышал? В нормальных конторах запрос на любые изменения (логические или физические) базы идут к data modeler (это может быть тот-же DBA) который вместе BA (business analyst) рассматривают запрос, отклоняют или утверждают (возможно с поправками) затем data modeler вносит изменения в model и генерирует DDL. И это не столько для базы сколько для бизнеса. Ведь это позволяет контролировать что тот-же самый business term всегда получает то-же имя поля во всех базах и если business term name or/and logic изменилась мы всегда знаем где менять.
SY.


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

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

Кто-то видел, как выгладит модель простой схемы? Можете показать?
...
Рейтинг: 0 / 0
Представление иерархии
    #40014654
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Правильный Вася
НеофитSQL
где вы держите схему взаимосвязей всех таблиц и представлений системы?

Для этого есть множество инструментов реверсивного вынимания схемы данных со всеми взаимосвязями и комментариями ко всем объектам и связям (если они прописаны в БД, в Оракле такое есть).
Т.е. это всегда актуально, именно в любой момент.

Кстати, если в твоей схеме 10 табличек для одного пользователя, то их можно и помнить :)
Реальные схемы содержат тысячи (а то и десятки тысяч) объектов схемы.


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

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

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

Чем pipelined-функция не устраивает?


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

Сравните:

Select col1 from table(func(3))

Против

Select col1 from VIEW_V where col2 = 3

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

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

Оптимизатору SQL абсолютно без разницы, где находится SQL - сам по себе, в анонимном блоке или в функции. Сравнение некорректное, так как не показаны внутренности func. А можно, например, так:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
Create Or Replace Function func(iNum In Number) Return tt Pipelined As
Begin
  For cur In (Select col1 From t Where col2 = iNum) Loop
    Pipe Row(tr(cur.col1));   
  End Loop;
  Return;
End;
/
...
Рейтинг: 0 / 0
Представление иерархии
    #40014726
Фотография env
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL
Можно имена одного-двух таких инструментов, совместимых с Ораклом

Power Designer, Visual Paradigm, ERwin и т.п., дальше нагуглите по аналогии.

Ещё раз, ваш "граф", при связях один ко многим даст нелепое размножение данных, по которому нет никакого смысла пытаться что-то понять. Union all в этом контексте был бы куда уместнее.

Хотите сделать понятную систему - вытащите объекты через reverse engineering, причешите имена таблиц и полей по доменам данных, прорисуйте необходимые связи. И все последующие изменения вносите через модель.

з.ы. Как же мне жаль несчастного, которому потом придётся в этом всём разбираться...
...
Рейтинг: 0 / 0
Представление иерархии
    #40015083
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
PuM256
НеофитSQL
пропущено...


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

Сравните:

Select col1 from table(func(3))

Против

Select col1 from VIEW_V where col2 = 3

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

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

Оптимизатору SQL абсолютно без разницы, где находится SQL - сам по себе, в анонимном блоке или в функции. Сравнение некорректное, так как не показаны внутренности func. А можно, например, так:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
Create Or Replace Function func(iNum In Number) Return tt Pipelined As
Begin
  For cur In (Select col1 From t Where col2 = iNum) Loop
    Pipe Row(tr(cur.col1));   
  End Loop;
  Return;
End;
/



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

View позволяет вычислять только то, что нужно запросу. Табличная функция будет вычислять все, т.к. не знает что нужно, а что нет.
...
Рейтинг: 0 / 0
Представление иерархии
    #40015084
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
env
НеофитSQL
Можно имена одного-двух таких инструментов, совместимых с Ораклом

Power Designer, Visual Paradigm, ERwin и т.п., дальше нагуглите по аналогии.

Ещё раз, ваш "граф", при связях один ко многим даст нелепое размножение данных, по которому нет никакого смысла пытаться что-то понять. Union all в этом контексте был бы куда уместнее.

Хотите сделать понятную систему - вытащите объекты через reverse engineering, причешите имена таблиц и полей по доменам данных, прорисуйте необходимые связи. И все последующие изменения вносите через модель.

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


А почему вы сами так не делаете?
...
Рейтинг: 0 / 0
Представление иерархии
    #40015090
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL

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

Потому что это неудобно.
Проработав с системой некоторое время осознаете, что никакие диаграммы Вам уже особо не нужны.
А сгенерировать приличный DDL из диаграммера - часто проблема.
Следствие - придется удвоить усилия, чтобы вести одновременно диаграмму и физическую схему данных.
...
Рейтинг: 0 / 0
Представление иерархии
    #40015091
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
andrey_anonymous
НеофитSQL

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

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


Я не подозревал, что вы вместе работаете..
...
Рейтинг: 0 / 0
Представление иерархии
    #40015092
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL
Я не подозревал, что вы вместе работаете..

Несмотря на то, что многие из присутствующих знакомы лично, данный конкретный вывод ошибочен.
...
Рейтинг: 0 / 0
Представление иерархии
    #40015093
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
andrey_anonymous

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


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

Например, в виде запроса.... :)
...
Рейтинг: 0 / 0
Представление иерархии
    #40015095
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL
Например, в виде запроса.... :)

"Твори, выдумывай, пробуй" (с).
Но данная конкретная идейка весьма и весьма посредственная.
...
Рейтинг: 0 / 0
Представление иерархии
    #40015101
Правильный Вася
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymous
НеофитSQL

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

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

Да, приличный DDL сгенерировать могут далеко не все средства. Но его можно "довести до нужной формы напильником".

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

Можно, конечно, уже ПОСЛЕ изменений в БД реверснуть их и добавить к существующей схеме. Это если она есть. А если совсем нет, то амба. Новый человек будет в ней плавать месяцами, пытаясь дедуктивным методом выяснить не только хранимые взаимосвязи, но и подразумеваемые бизнес-логикой, но не ложащиеся по каким-то причинам в схему данных.
...
Рейтинг: 0 / 0
Представление иерархии
    #40015118
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Правильный Вася
andrey_anonymous
Следствие - придется удвоить усилия, чтобы вести одновременно диаграмму и физическую схему данных.

Да, приличный DDL сгенерировать могут далеко не все средства. Но его можно "довести до нужной формы напильником".
А вот работать с системой, не имея документации, значит замкнуть на себя всю разработку и поддержку. Потому как никто иной в каше не разберётся, если система не из 10 табличек, а, как я уже говорил, из многих тысяч.

1. Про напильник: доведенный DDL надо как-то распространять. Т.е. уложить в систему контроля версий и отдать девопсам. С этого момента диаграмма и DDL разошлись, синхронизация крайне затруднена.
2. Документация обязательна, диаграммы - нет.
Важной частью внутренней документации является стандарт разработки.
Частью стандарта разработки является стандарт именования.
Хорошая система именования объектов в совокупности с продуманной схемой способна существенно систематизировать "кашу" даже в отсутствие FK.
В качестве одного из достаточно хороших, на мой взгляд, общедоступных примеров такого рода могу привести продукт oracle cbrm - с его концепцией и схемой данных вопросов вида "кто на ком стоял" практически не возникало ни на уровне схемы данных, ни на уровне мэппинга объектов приложения. Диаграмму я брал в руки один раз, после чего отложил и более не прикасался.
...
Рейтинг: 0 / 0
Представление иерархии
    #40015429
Фотография env
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL
А почему вы сами так не делаете?

Обоснуйте
...
Рейтинг: 0 / 0
Представление иерархии
    #40015633
НеофитSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
env
НеофитSQL
А почему вы сами так не делаете?

Обоснуйте


Психология 101: если бы вы это делали, ответ был бы "я так и делаю".

А вы полезли в бутылку.
...
Рейтинг: 0 / 0
Представление иерархии
    #40015636
Фотография env
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НеофитSQL,

А, доморощенный психолог. Мимо.
...
Рейтинг: 0 / 0
58 сообщений из 58, показаны все 3 страниц
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Представление иерархии
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]