MonetDB рекурсивный CTE (общие табличные выражения) - PullRequest
Новая
       17

MonetDB рекурсивный CTE (общие табличные выражения)

0 голосов
/ 24 сентября 2018

Кажется, MonetDB не поддерживает рекурсивный CTE.Это полезная функция, которую я использовал для получения спецификации систем ERP.Для большей гибкости я использовал рекурсивные хранимые процедуры Firebird, чтобы улучшить вывод с помощью дополнительных вычислений.Хороший пример рекурсивного CTE SQLServer можно найти здесь https://www.essentialsql.com/recursive-ctes-explained/

Вопрос в том, можно ли каким-либо образом добиться подобных результатов в MonetDB?

Ответы [ 2 ]

0 голосов
/ 25 сентября 2018

В настоящее время нет поддержки рекурсивных CTE в MonetDB [Lite].Решение, которое вы сами предложили, похоже на путь.

0 голосов
/ 24 сентября 2018

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

CREATE TEMPORARY TABLE BOM (parent_id string, comp_id string, qty double) ON COMMIT PRESERVE ROWS;
INSERT INTO BOM VALUES('a','b',5), ('a','c',2), ('b','d',4), ('b','c',7), ('c','e',3);

select * from BOM;
+-----------+---------+--------------------------+
| parent_id | comp_id | qty                      |
+===========+=========+==========================+
| a         | b       |                        5 |
| a         | c       |                        2 |
| b         | d       |                        4 |
| b         | c       |                        7 |
| c         | e       |                        3 |
+-----------+---------+--------------------------+

CREATE TEMPORARY TABLE EXPLODED_BOM (parent_id string, comp_id string, path string, qty double, level integer) ON COMMIT PRESERVE ROWS;

CREATE OR REPLACE PROCEDURE UPDATE_BOM()
BEGIN

    DECLARE prev_count int;
    DECLARE crt_count int;
    DECLARE crt_level int;


    delete from EXPLODED_BOM; --make sure is empty
    insert into EXPLODED_BOM select parent_id, comp_id, parent_id||'-'||comp_id, qty, 0 from BOM; --insert first level

    SET prev_count = 0;
    SET crt_count = (select count(*) from EXPLODED_BOM);
    SET crt_level = 0;

    -- (crt_level < 100) avoids possible infinite loop, if BOM is malformed 
    WHILE (crt_level < 100) and (crt_count > prev_count) DO
        SET prev_count = crt_count;
        insert into EXPLODED_BOM select e.parent_id, a.comp_id, e.path||'-'||a.comp_id, a.qty*e.qty, crt_level+1 
        from BOM a, EXPLODED_BOM e
        where a.parent_id = e.comp_id and e.level=crt_level; 

        -- is it any chance to get the amount of "affected rows" by insert, update or delete statements, this way I can avoid checking the new count?
        SET crt_count = (select count(*) from EXPLODED_BOM);  
        SET crt_level = crt_level +1; 
    END WHILE;

END;

call UPDATE_BOM();

select * from EXPLODED_BOM;

+-----------+---------+---------+--------------------------+-------+
| parent_id | comp_id | path    | qty                      | level |
+===========+=========+=========+==========================+=======+
| a         | b       | a-b     |                        5 |     0 |
| a         | c       | a-c     |                        2 |     0 |
| b         | d       | b-d     |                        4 |     0 |
| b         | c       | b-c     |                        7 |     0 |
| c         | e       | c-e     |                        3 |     0 |
| a         | d       | a-b-d   |                       20 |     1 |
| a         | c       | a-b-c   |                       35 |     1 |
| a         | e       | a-c-e   |                        6 |     1 |
| b         | e       | b-c-e   |                       21 |     1 |
| a         | e       | a-b-c-e |                      105 |     2 |
+-----------+---------+---------+--------------------------+-------+
...