Напоминаю, у нас тут только по существу.

Ну потому что совершенно нехарактерная задача для реляционной СУБД.

Это по существу.

Определение реляционной таблицы: это неупорядоченное множество записей.

Мне ее в качестве тестового присылали на вакансию как-то

Очень плохо.

Нет. Это про обсудить. Обсуждения у нас в соседнем чате. Здесь нет проблемы. Здесь есть только мнение.

Подскажите плиз, как изменить схему партиционирования HEAP талицы?
Толкьо пересоздавать таблицу?

или, повесить туда кластерный индекс с новой схемой партиционировния, после чего дропнуть его?

Если есть возможность создать новую таблицу с новой схемой и перелить в нее данные лучше так и сделать
И переливать пачками по Н строк
Это если табла большая

а почему лучше чем вариант с созданием/удалением индекса?
а хотя глупый вопрос, понятно что лишняя операция...

Долгая блокировка, раздуется транзакшин лог
Ну и по времени может занять больше
А в случае ошибки еще откат транзакции

Простите за вопрос, но heap это осознанный выбор? Если секционировать надо, значит таблица большая. Большие кучи это довольно плохо в целом

Да, таблицы раньше использовались как временные, потом делался switch partition в основную.
впринципе, сейчас я их просто акуратно дропаю :)

Есть еще один очень плохой момент - если на куче есть некластерные индексы, то создание кластерного индекса вызовет их перестройку. Удаление кластерного индекса - тоже.

Не понял тогда, зачем секционировать то, что дропается?

потому что я спрашиваю быстрее чем соображаю)
уже незачем. Но всеравно интересно было)
плюс обнаружил несколько хип таблиц где дейсвительно хип - неосознанный выбор, но туда всунем колумнстор партиционированый.

ну и если что - это не прод, just to be clear
поднимаем и чистим старый тестовый сервак.

окей. понял. удачи

Чисто гипотетический вопрос - допустим есть простая таблица-куча, где есть 3 столбца. Код клиента, тип документа и сумма.

Тип документов бывает двух видов - продажа и возврат (текстовое поле), сумма - всегда положительный инт. Код клиента - инт.

Что больше ресурсов системы сожрет, если нужно посчитать результат (продажи - возвраты) по клиенту

Есть два варианта кода - первый - это кейс с суммированием sum(case when d=накладная then sale else -sale)

Второй вариант - это селект из вложенного юниона:

Select tt, sum(totalsum) from
(Select tt, sale from tbl where d=накладная
Union all
Select tt,-sale from tbl where d=возврат) r1
Group by tt