Заказать По внутреннему виду в снежинке, чтобы создать уникальный идентификатор - PullRequest
0 голосов
/ 15 января 2020

Мой код генерирует уникальный идентификатор для каждой строки (8 миллионов строк данных). Если я положу ORDER BY внутри CREATE VIEW AS..., будет ли порядок строк одинаковым?

Ожидаемый результат будет всегда иметь одинаковое ID независимо от того, кто и когда выполняет представление. Я читал, что ORDER BY оператор внутреннего представления не гарантирует сортировку по умолчанию c, а использование ORDER BY вне представления позволит ему работать.

Снежинка dwh работает по-другому? Из того, что я вижу в плане выполнения, это кажется прямым: звездочки из нижнего вложенного запроса и движущиеся вверх при выполнении операций)

Может, вместо представления мне нужно просто go с таблицей?

--sample data
create or replace table determin_sort as (

select uuid,position,val1,val2 
from values ('u98rutu', 66788, 1, 3), 
            ('u999etd', 66788, 2,3), 
            ('voko225', 66788, 2,3),
            ('pp29ccd', 229, 20, 30), 
            ('aa55jmw', 229, 2, 3), 
            ('1ojcugi7', 8994, 2, 30), 
            ('2yrhbf',8994,20,3) 

            v(uuid,position,val1,val2)
);


--view
create or replace view v_determin_sort as

SELECT 'L'||row_number() over (order by position) as LID 
        uuid, 
        position,
        val1,
        val2 FROM (SELECT 
                   row_number() over (partition by position order by uuid) as rn, * 
                   FROM determin_sort
                   QUALIFY row_number() over (partition by position order by uuid) = 1
                   ORDER BY UUID);
--query the view
SELECT * FROM v_determin_sort ORDER BY LID;

Ответы [ 2 ]

2 голосов
/ 15 января 2020

Мой код генерирует уникальный идентификатор для каждой строки (8 миллионов строк данных). Если я положу ORDER BY внутри CREATE VIEW AS ... будет ли это сохранять порядок строк одинаковым?

Значение ORDER BY UUID, которое вы имеете в под-выборе представления, не имеет смысла, о чем свидетельствует строки, которые заботятся о порядке (ROW_NUMBER), имеют свои ORDER BY *

Ожидаемый результат будет иметь всегда один и тот же идентификатор, независимо от того, кто и когда выполняет представление. Я читал, что оператор ORDER BY внутри представления не гарантирует сортировку по принципу stati c, а использование ORDER BY вне представления позволит ему работать. «в этот момент времени, но если вы присоедините таблицу к какой-то другой таблице, сначала с другой таблицей, порядок представлений будет иметь меньшее значение.

SELECT t.*, v.*
FROM table_name AS t
JOIN view_name AS v ON t.uuid = v.uuid

данные могут упорядочивать эти строки в любом мода это нравится. И если к этому запросу добавлен порядок, например ORDER BY t.column_a какое значение было создано путем упорядочения внутри представления, это все представление.

Тем важнее, если вы хотите, чтобы идентификаторы были стабильными, требует, чтобы значения, используемые в ORDER BY, использованных в ROW_NUMBERS, были стабильными (иначе говоря, нет дубликатов для ваших примеров данных в UUID).

CREATE OR REPLACE VIEW v_determin_sort AS
SELECT 
    'L' || row_number() OVER (ORDER BY position) AS lid 
    ,uuid
    ,position
    ,val1
    ,val2
FROM (
    SELECT 
        row_number() OVER (PARTITION BY position ORDER BY uuid) AS rn /* this row is not needed as the QUALIFY is doing the work */
        ,uuid
        ,position
        ,val1
        ,val2
    FROM determin_sort
    QUALIFY row_number() OVER (PARTITION BY position ORDER BY uuid) = 1
    ORDER BY UUID /* this order by does nothing */
);

Это даст те же результаты, КАК ДОЛГО КАК данные в таблице не изменятся, если новые / 1025 * или 'UUID' будут вставлены / удалены, вы получите разные результаты при этих изменениях. Кроме того, UUID представляется строкой, которая кажется странным значением для сортировки, поскольку UUID часто являются случайными в тех битах, которые установлены относительно времени, так почему один UUID более допустим как лучший / последний / наиболее требуемый UUID для любого position

1 голос
/ 15 января 2020

Нет никакой гарантии, что вы будете получать один и тот же номер LID для одной и той же строки при каждом запуске представления , если только ваш ORDER BY в оконной функции не является уникальным .

Если вы Если бы вы заказывали по LID в представлении, я полагаю, что в этом конкретном случае c вам будет хорошо, потому что вы сначала вычисляете столбец LID, а затем сортируете его. Хотя я бы не советовал добавлять операцию сортировки в представление, так как сортировка является дорогой операцией.

...