Size: a a a

SqlCom.ru - Стиль жизни SQL

2021 January 25

B

Bu in SqlCom.ru - Стиль жизни SQL
Gopneg
есть конечно нюанс один, раз ты бигинт и строку в одно поле суешь, нет ли у тебя хранения чисел как строки в том поле?
если да, то это конечно надо убирать, станет быстрее и меньше места занимать будет
ответа нет на этот вопрос, историческая тема
источник

G

Gopneg in SqlCom.ru - Стиль жизни SQL
ну если из-за этого страдает производительность, то вопрос придется решить
но не думаю что сильно критично, больше наверное проблем у тебя с тем что индексов нет или джойны по функциям тому подобное
источник

O

Oleg T in SqlCom.ru - Стиль жизни SQL
Bu
то есть никак особо не повлияет? и могу смело так фигачить?
привет. есть одна упячка о которой стоит знать, применяя юнионы. Если запрос будет использоваться в сценариях, когда результат выборки - данные только из одной таблицы, входящей в юнион, то кешированный план запроса вызовет обращение ко всем таблицам в любом случае. РАботать нормально будет только при рекомпиляции. Некогда аналогичная ситуация вынудила меня кардинально пересмотреть подход и пойти на денормализацию в чистой OLTP системе. Готов предоставить больше подробностей, если потребуется.
источник

KT

Konstantin Taranov in SqlCom.ru - Стиль жизни SQL
Oleg T
привет. есть одна упячка о которой стоит знать, применяя юнионы. Если запрос будет использоваться в сценариях, когда результат выборки - данные только из одной таблицы, входящей в юнион, то кешированный план запроса вызовет обращение ко всем таблицам в любом случае. РАботать нормально будет только при рекомпиляции. Некогда аналогичная ситуация вынудила меня кардинально пересмотреть подход и пойти на денормализацию в чистой OLTP системе. Готов предоставить больше подробностей, если потребуется.
давай конечно больше подробностей
источник

O

Oleg T in SqlCom.ru - Стиль жизни SQL
Представь, что у тебя есть разнородные сущности. Каждый вид сущности хранится в отдельной таблице. НО у них у всех есть несколько общих атрибутов. Например это данные об оъектах инфраструкты в CMDB. Есть серверы, есть экземпляры, есть базы, есть файлы и т.п. Сущности имеют глобальный ID, который берется из sequence. Как по ID найти сущность? нужен глобальный каталог - вьюха с юнионом из всех этих таблиц. Только вот беда - ищешь по ней горстку экземпляров или баз, а в плане видишь, что он пылесосит все таблицы, входящие во вьюху. Приходится всегда делать recompile. На втором уровне вложенности он перестаёт срабатывать (вьюха в функции в процедуре) - пишешь рекомпайл, а рекомпилится только исходное выражение, а план вьюхи включается без компиляции.
источник

IZ

Ilia Zviagin in SqlCom.ru - Стиль жизни SQL
Sergey
Всем привет. Друзья, есть вопрос который давно волнует и остаётся непонятным. Хочется уже прояснить ситуацию.
Для того чтобы база данных правильно работала и соблюдались некие нормы - проводят нормализацию. Соответственно, схема бд приобретает вид таблиц справочников и таблиц фактов со связями.
Но в реальности данные на вход базы поступают в виде плоской таблицы из 100+ столбцов, имеющих совершенно разное смысловое содержание. Как в таком случае быть? Проводить нормализацию? или использовать как есть?
Я просто понимаю, что если нормализацию провести, потом для формирования views будет 30-50 join'ов, что тоже не хорошо.
Разбирают данные на части, и запихивают по разным таблицам.
источник

IZ

Ilia Zviagin in SqlCom.ru - Стиль жизни SQL
Oleg T
Представь, что у тебя есть разнородные сущности. Каждый вид сущности хранится в отдельной таблице. НО у них у всех есть несколько общих атрибутов. Например это данные об оъектах инфраструкты в CMDB. Есть серверы, есть экземпляры, есть базы, есть файлы и т.п. Сущности имеют глобальный ID, который берется из sequence. Как по ID найти сущность? нужен глобальный каталог - вьюха с юнионом из всех этих таблиц. Только вот беда - ищешь по ней горстку экземпляров или баз, а в плане видишь, что он пылесосит все таблицы, входящие во вьюху. Приходится всегда делать recompile. На втором уровне вложенности он перестаёт срабатывать (вьюха в функции в процедуре) - пишешь рекомпайл, а рекомпилится только исходное выражение, а план вьюхи включается без компиляции.
Наследование используй, сразу пол проблем уйдёт
источник

O

Oleg T in SqlCom.ru - Стиль жизни SQL
Ilia Zviagin
Наследование используй, сразу пол проблем уйдёт
Наследование в SQL Server?
источник

S

Sergey in SqlCom.ru - Стиль жизни SQL
Ilia Zviagin
Разбирают данные на части, и запихивают по разным таблицам.
Привет. Ну я так и собственно говорил. Типа разбивать на таблицы фактов и справочники, потом кодировать таблицу фактов по id и дальше уже заливать в базу
источник

O

Oleg T in SqlCom.ru - Стиль жизни SQL
Ilia Zviagin
Наследование используй, сразу пол проблем уйдёт
Даже в postgresql наследование это весьма сомнительная фича для таблиц крупных размеров, как были у нас. яб не парился, если бы пришлось сканировать таблицы в 1000 записей каждая, но там было существенно больше.
источник

IZ

Ilia Zviagin in SqlCom.ru - Стиль жизни SQL
Oleg T
Наследование в SQL Server?
Оно в любой рсубд возможно, это прием проектирования, а не фича СУБД
источник

IZ

Ilia Zviagin in SqlCom.ru - Стиль жизни SQL
Sergey
Привет. Ну я так и собственно говорил. Типа разбивать на таблицы фактов и справочники, потом кодировать таблицу фактов по id и дальше уже заливать в базу
Да
источник

IZ

Ilia Zviagin in SqlCom.ru - Стиль жизни SQL
Oleg T
Даже в postgresql наследование это весьма сомнительная фича для таблиц крупных размеров, как были у нас. яб не парился, если бы пришлось сканировать таблицы в 1000 записей каждая, но там было существенно больше.
А при чем тут это?
источник

O

Oleg T in SqlCom.ru - Стиль жизни SQL
Ilia Zviagin
Оно в любой рсубд возможно, это прием проектирования, а не фича СУБД
Как это поможет решить проблему, описанную мною?
источник

S

Sergey in SqlCom.ru - Стиль жизни SQL
Самый прикол что потом их опять join ами соединять и выгружать пользователям..
источник

O

Oleg T in SqlCom.ru - Стиль жизни SQL
Ilia Zviagin
А при чем тут это?
ну, у нас проблема то была именно в нежелательном и ненужном сканировании, предпринимаем оптимизатором, потому как он не мог заранее понять, что данные нужны только из отдельных таблиц, входящих в UNION.
источник

IZ

Ilia Zviagin in SqlCom.ru - Стиль жизни SQL
Oleg T
Как это поможет решить проблему, описанную мною?
вид сущности хранится в отдельной таблице. НО у них у всех есть несколько общих атрибутов
источник

IZ

Ilia Zviagin in SqlCom.ru - Стиль жизни SQL
Sergey
Самый прикол что потом их опять join ами соединять и выгружать пользователям..
Чем тебе JOIN ы так не нравятся?
источник

O

Oleg T in SqlCom.ru - Стиль жизни SQL
Ilia Zviagin
вид сущности хранится в отдельной таблице. НО у них у всех есть несколько общих атрибутов
Да, это было реализовано через механизм расширенных свойств, лежащих в отдельной темпоральной таблице
источник

O

Oleg T in SqlCom.ru - Стиль жизни SQL
Ilia Zviagin
Чем тебе JOIN ы так не нравятся?
с языка снял 😊
источник