IB
обычная практика добавлять поля "ТипСтроки" и все формулы делать вида SUM({<ТипСтроки={1}>} ЯвляетсяЧеком), где ЯвляетсяЧеком это поле содержит 1 или 0 для каждой уникальной строки а ТипСтроки=1 это признак уникальной строки чека
Size: a a a
2021 March 31
IB
Бывает еще что все поля заменяют на Сумма1, Сумма2, Сумма3, Количество1, Количество2, Количество3 дабы избежать сотен столбцов в таблице фактов
IB
и все получается быстро и компактно, но абсолютно не читаемо без отдельной таблицы в Excel где прописаны все эти связи-коды-что-где-находится 😂
ЕС
Самая простая модель это когда в центре таблица фактов просто всех без особого разобра, даже тех которые слабо связаны друг с другом (например продажи товаров и записи о регистрации пользователей на сервисе) а по бокам она как ежик утыкана справочниками. Получается топология звезда. У данной схемы есть минусы конечно, но главный плюс это то что она производительнее Link table, поскольку в Link Table надо на один "прыжок" между таблицами больше совершать, а на больших размерах таблиц "прыжок" через большую таблицу (саму Link Table) будет затратный
только при таком подходе если таблица имеет более одной даты для единого календаря, ее придется несколько раз загружать, в результате данные этой таблицы будут дублированы
GE
Самая простая модель это когда в центре таблица фактов просто всех без особого разобра, даже тех которые слабо связаны друг с другом (например продажи товаров и записи о регистрации пользователей на сервисе) а по бокам она как ежик утыкана справочниками. Получается топология звезда. У данной схемы есть минусы конечно, но главный плюс это то что она производительнее Link table, поскольку в Link Table надо на один "прыжок" между таблицами больше совершать, а на больших размерах таблиц "прыжок" через большую таблицу (саму Link Table) будет затратный
Я тоже все к такой модели стараюсь привести, и собрать проще, и нет выкрутасов с set analyses про которые иногда Евгений пишет, и производительность оптимальная
IB
только при таком подходе если таблица имеет более одной даты для единого календаря, ее придется несколько раз загружать, в результате данные этой таблицы будут дублированы
да. либо в таблице фактов отдельно отдельное поле для отдельного еще одного календаря
IB
отдельное поле в таблице с сотней полей не мешает)
IB
есть еще нюанс - когда это показываешь заказчику если он знает СУБД реляционные возможны споры)
ЕС
Я тоже все к такой модели стараюсь привести, и собрать проще, и нет выкрутасов с set analyses про которые иногда Евгений пишет, и производительность оптимальная
как вы в такой модели сделаете возможность из одной таблицы по 2-м типам дат агрегировать данные на одной оси? Как решите кейс связи один-ко многим, когда на 1 элемент несколько других, типа на 1 сделку 3 контакта?
ЕС
Модели со сбором фактов в центральную таблицу несомненно являются оптимальными по производительности, но с точки зрения гибкости сценариев связи далеко не универсальны
IB
как вы в такой модели сделаете возможность из одной таблицы по 2-м типам дат агрегировать данные на одной оси? Как решите кейс связи один-ко многим, когда на 1 элемент несколько других, типа на 1 сделку 3 контакта?
только через дополнительные поля. Да это существенный минус
GE
как вы в такой модели сделаете возможность из одной таблицы по 2-м типам дат агрегировать данные на одной оси? Как решите кейс связи один-ко многим, когда на 1 элемент несколько других, типа на 1 сделку 3 контакта?
Я же сказала стараюсь 😉, а с другой стороны , на данные и нп задачу тоже смотреть надо. У меня ваши примеры не часто встречались в практике, к счастью.
Я же про другие мпособы тоже помню.
Я же про другие мпособы тоже помню.
IB
Вообще хорошо что в жизни есть разнообразие - можно одно и то же сделать разными способами и получить разные преимущества
VL
[QlikView] Привет, коллеги. Есть очень огромная таблица с кучей столбцов и есть вторая такая же таблица. Как их сравнить между собой, чтобы выяснить по каким строкам/столбцам есть расхождение? Может для QV есть специальный инструмент?
ЕС
Я же сказала стараюсь 😉, а с другой стороны , на данные и нп задачу тоже смотреть надо. У меня ваши примеры не часто встречались в практике, к счастью.
Я же про другие мпособы тоже помню.
Я же про другие мпособы тоже помню.
:) Лично для меня модели с центральной таблицей фактов являются крайней степенью оптимизации, на которую иду только при необходимости. И предложенная таблица связи может быстро быть преобразована к этому типу. Можно поля мер в нее засовывать на этапе когда идет отбор полей во временные таблицы)
Опять же, очень удобно когда поле переносится в центр с префиксом своей таблицы в названии. Тогда можно работать с такой моделью и не париться о синтаксисе формул. Будет не важно, находится ли поле в центральной таблице или в таблице-луче.
Опять же, очень удобно когда поле переносится в центр с префиксом своей таблицы в названии. Тогда можно работать с такой моделью и не париться о синтаксисе формул. Будет не важно, находится ли поле в центральной таблице или в таблице-луче.
ei
Vasily Lebedev
[QlikView] Привет, коллеги. Есть очень огромная таблица с кучей столбцов и есть вторая такая же таблица. Как их сравнить между собой, чтобы выяснить по каким строкам/столбцам есть расхождение? Может для QV есть специальный инструмент?
если есть какой-нибудь уникальный ключ (или несколько полей формирующих уникальный ключ) то, сделать outer join по этим полям, а другие поля уже сравнивать между собой
IB
Vasily Lebedev
[QlikView] Привет, коллеги. Есть очень огромная таблица с кучей столбцов и есть вторая такая же таблица. Как их сравнить между собой, чтобы выяснить по каким строкам/столбцам есть расхождение? Может для QV есть специальный инструмент?
Решение в лоб - сделать ключ по полям в обоих и сверить. Но это жесть по производительность будет
VL
Решение в лоб - сделать ключ по полям в обоих и сверить. Но это жесть по производительность будет
Понял, спасибо. Попробую через циклы сверять каждый столбец и отличия выводить в отдельную табл. Неважно насколько долго, это для теста
VL
evgeny ivanov
если есть какой-нибудь уникальный ключ (или несколько полей формирующих уникальный ключ) то, сделать outer join по этим полям, а другие поля уже сравнивать между собой
Да, буду по ключу. Спасибо
EI
Vasily Lebedev
[QlikView] Привет, коллеги. Есть очень огромная таблица с кучей столбцов и есть вторая такая же таблица. Как их сравнить между собой, чтобы выяснить по каким строкам/столбцам есть расхождение? Может для QV есть специальный инструмент?
если есть набор ключевых полей и числовые поля для сверки, я обычно гружу их в одну таблицу, с инверсией числовых полей одной из таблиц.
в идеале суммы по ключам должны быть равны 0
в идеале суммы по ключам должны быть равны 0