K
ну, естно
Size: a a a
2020 May 28
K
опять же вот этого вот ныряния постоянного в HEAP нет уже
K
Короче вот если это кластер уникальный и даже ключ секции
110 Мб на 34 млн строк примерно он занимает, если БигИнт
Вот льются данные смотрю
110 Мб на 34 млн строк примерно он занимает, если БигИнт
Вот льются данные смотрю
2020 May 29
K
а для таблиц с кластерными индексами по полям типа uniquedentefier, насколько все плохо по производительности? (ms sql 2016)
Я не вдавался в эту тему, к сожалению, или к счастью, как удобнее :)))
Вот Гопнег ощенама любит юиды :))).
Если у Микрософта нет толкового механизма их индексации. то, вангую, все очень плохо.
Гораздо (с), ДМБ :)))
Примерно такую же лабудень заниет девайс_айди у андрюши, и вот с ним по сфере приходилось работать.
Весьма тягомотно, настолько, что при переваливании таблицы за 20 млн строк при количестве активных дивайсов в районе пары тысяч я создал таблу-справочник и лишним запросом ключевал фактовую таблу на лету :)))
Вот Гопнег ощенама любит юиды :))).
Если у Микрософта нет толкового механизма их индексации. то, вангую, все очень плохо.
Гораздо (с), ДМБ :)))
Примерно такую же лабудень заниет девайс_айди у андрюши, и вот с ним по сфере приходилось работать.
Весьма тягомотно, настолько, что при переваливании таблицы за 20 млн строк при количестве активных дивайсов в районе пары тысяч я создал таблу-справочник и лишним запросом ключевал фактовую таблу на лету :)))
K
И уже по ключу строил индекс
K
Но там были обычные индексы и дивайс_айди варчар поле.
А с юидом все же скуль что-то отдельное мутит, везде сноски на типа индивидуальный подход :)))
Все дела и сбоку бантик :)))
А с юидом все же скуль что-то отдельное мутит, везде сноски на типа индивидуальный подход :)))
Все дела и сбоку бантик :)))
K
Офф библия
K
K
With the indexes rebuilt we now see almost no performance difference between the two datatypes. Assuming you are running regular maintenance on your indexes this simple test shows that you achieve pretty much identical performance between the two datatypes. One thing to also note is that the GUID column also gives you the added benefit of uniqueness across systems. If any of your applications merge data generated from different systems then using a GUID column as your key allows you to not have to worry about resolving any duplicates when you merge the data.
K
В общем-то, вот конкретно твой случай
K
Я бы отталкивался от архитектуры. Если у вас множество систем, которые должны передавать что то друг дружке и постоянно синхронизироваться, выбрал бы уид. Ибо бигинт только бить по диапазонам, а они когда то кончаются.
не только лишь все не согласятся:),да.
Здесь бытие определит сознание (с)
Здесь бытие определит сознание (с)