DI
Для начала надо определить тип хранилища, прежде чем нормализовать или нет.
Size: a a a
2021 January 24
Л
Для начала надо определить тип хранилища, прежде чем нормализовать или нет.
Это да
S
Для начала надо определить тип хранилища, прежде чем нормализовать или нет.
Согласен, Dwh
DI
Если OLTP - то вероятно, что стоит нормализовать.
Если DWH, то выбор между data vault\anchor model\и полной денормализацией.
По последней модели недавно смотрел статистику, она на 30-50% быстрее по чтению\записи, но места занимает в разы больше, зато простая для понимания.
Также стоит учесть как у вас будут храниться исторические данные для каждой модели и как вы будете отображать эти изменения.
Если DWH, то выбор между data vault\anchor model\и полной денормализацией.
По последней модели недавно смотрел статистику, она на 30-50% быстрее по чтению\записи, но места занимает в разы больше, зато простая для понимания.
Также стоит учесть как у вас будут храниться исторические данные для каждой модели и как вы будете отображать эти изменения.
S
Если OLTP - то вероятно, что стоит нормализовать.
Если DWH, то выбор между data vault\anchor model\и полной денормализацией.
По последней модели недавно смотрел статистику, она на 30-50% быстрее по чтению\записи, но места занимает в разы больше, зато простая для понимания.
Также стоит учесть как у вас будут храниться исторические данные для каждой модели и как вы будете отображать эти изменения.
Если DWH, то выбор между data vault\anchor model\и полной денормализацией.
По последней модели недавно смотрел статистику, она на 30-50% быстрее по чтению\записи, но места занимает в разы больше, зато простая для понимания.
Также стоит учесть как у вас будут храниться исторические данные для каждой модели и как вы будете отображать эти изменения.
Просто в некоторых случаях я понимаю, что мне гораздо удобнее было бы просто данные дозаписывать в уже имеющуюся шаблонную денормализованную выгрузку и кидать во вьюшку нужные столбцы из неё, группируя по измерениям..
Если же я буду её нормализовывать, то потом на выходе мне придётся её обратно денормализовывать и выдавать пользователям. Что как мне кажется не здорово.
Если же я буду её нормализовывать, то потом на выходе мне придётся её обратно денормализовывать и выдавать пользователям. Что как мне кажется не здорово.
S
Хотя я понимаю, что избыточность данных и большой расход памяти будут
DI
Просто в некоторых случаях я понимаю, что мне гораздо удобнее было бы просто данные дозаписывать в уже имеющуюся шаблонную денормализованную выгрузку и кидать во вьюшку нужные столбцы из неё, группируя по измерениям..
Если же я буду её нормализовывать, то потом на выходе мне придётся её обратно денормализовывать и выдавать пользователям. Что как мне кажется не здорово.
Если же я буду её нормализовывать, то потом на выходе мне придётся её обратно денормализовывать и выдавать пользователям. Что как мне кажется не здорово.
Поэтому я вам и пишу, что вам нужно выбрать приоритет.
Вы хотите меньше хранить и быстро писать - нормализация.
Хотите быстро читать и не важно на хранение - денормализация.
Опять же вопрос по истории изменений, для каждой модели он свой.
Вы хотите меньше хранить и быстро писать - нормализация.
Хотите быстро читать и не важно на хранение - денормализация.
Опять же вопрос по истории изменений, для каждой модели он свой.
DI
Хотя я понимаю, что избыточность данных и большой расход памяти будут
S
Поэтому я вам и пишу, что вам нужно выбрать приоритет.
Вы хотите меньше хранить и быстро писать - нормализация.
Хотите быстро читать и не важно на хранение - денормализация.
Опять же вопрос по истории изменений, для каждой модели он свой.
Вы хотите меньше хранить и быстро писать - нормализация.
Хотите быстро читать и не важно на хранение - денормализация.
Опять же вопрос по истории изменений, для каждой модели он свой.
Да, я понял. Не совсем понял по колоночному хранению что писали. У нас sql server 2019 инструмент
DI
Да, я понял. Не совсем понял по колоночному хранению что писали. У нас sql server 2019 инструмент
Это лишь тип хранения данных и соответственно доступ к ним.
Он понадобиться уже после того как вы выберите методологию для вашего хранилища.
Иногда такие индексы используют в OLTP-системах, для создания гибридов. Что-то среднее между oltp и dwh
Он понадобиться уже после того как вы выберите методологию для вашего хранилища.
Иногда такие индексы используют в OLTP-системах, для создания гибридов. Что-то среднее между oltp и dwh
S
Это лишь тип хранения данных и соответственно доступ к ним.
Он понадобиться уже после того как вы выберите методологию для вашего хранилища.
Иногда такие индексы используют в OLTP-системах, для создания гибридов. Что-то среднее между oltp и dwh
Он понадобиться уже после того как вы выберите методологию для вашего хранилища.
Иногда такие индексы используют в OLTP-системах, для создания гибридов. Что-то среднее между oltp и dwh
Ок, спасибо🤝
2021 January 25
B
Всем привет, помогите пожалуйста решить проблему, есть 2 запроса которые я пытаюсь объединить Union`ом у одного поля(на самом деле оно там не одно, это для примера) разные типы, следовательно ошибка. как ее обойти что-бы не потерять в производительности
G
а у тебя проблема с производительностью?
IC
Bu
Всем привет, помогите пожалуйста решить проблему, есть 2 запроса которые я пытаюсь объединить Union`ом у одного поля(на самом деле оно там не одно, это для примера) разные типы, следовательно ошибка. как ее обойти что-бы не потерять в производительности
Как вы колонку назовете, так она и поплывет 😂
А особых проблем с производительностью не должно быть, это же не предикат.
А особых проблем с производительностью не должно быть, это же не предикат.
B
а у тебя проблема с производительностью?
у меня есть большой запрос, который собирается из нескольких хранимок,выполняется он долго, я хочу попробовать собраться это все "одним" запросом и проверить будет ли ускорение.
G
ну тогда вряд ли у тебя проблема с кастом будет
B
ну тогда вряд ли у тебя проблема с кастом будет
то есть никак особо не повлияет? и могу смело так фигачить?
G
ну если тебе нужна строка, то делай строку, выход-то какой?
G
тут проблема ведь не в производительности, а в условии задачи
если тебе надо строку - хоть об стену расшибись, но придется строку
если тебе надо строку - хоть об стену расшибись, но придется строку
G
есть конечно нюанс один, раз ты бигинт и строку в одно поле суешь, нет ли у тебя хранения чисел как строки в том поле?
если да, то это конечно надо убирать, станет быстрее и меньше места занимать будет
если да, то это конечно надо убирать, станет быстрее и меньше места занимать будет