Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 хранимая процедура для пересоздания ограмной таблици. Может так не надо?  [new]
FatumX
Member

Откуда: Минск
Сообщений: 61
Пишем приложение с БД. Разработчики придумали раз в сутки дропать таблицу и соответственно потом ее-же пере создавать уже пустой, для последующего импорта в нее очень большого объема данных(порядка 10 млн. строк) из некоего xml-файлика. Каждый день файлик новый. Простая очистка таблицы разработчику не нравится. Говорит уж очень медленно. Хочет использовать для этого хранимую процедуру, давать учетной записи приложения права на удаление и создание объектов в БД мне очень не хочется. Опять же удаление и пхание больших объемов одновременно, наверное приведет к диким тормозам. MS SQL server 2016.
Хочу узнать мнение сообщества.
3 окт 19, 10:53    [21985618]     Ответить | Цитировать Сообщить модератору
 Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?  [new]
mnbvcx
Member

Откуда:
Сообщений: 164
FatumX
Простая очистка таблицы разработчику не нравится. Говорит уж очень медленно.

TRUNCATE медленно?!
3 окт 19, 10:56    [21985621]     Ответить | Цитировать Сообщить модератору
 Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?  [new]
FatumX
Member

Откуда: Минск
Сообщений: 61
можешь пояснить.
3 окт 19, 10:58    [21985625]     Ответить | Цитировать Сообщить модератору
 Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?  [new]
teCa
Member

Откуда:
Сообщений: 499
FatumX,

Ну из всех видов очисток таблицы truncate, пожалуй, самый быстрый. Нужно понимать, как данные в этих 10млн строк ежедневно меняются. Если нужно вычистить 9999999 записей и оставить только одну, то пожалуй быстрее действительно сделать truncate и просто загружать данные заново.
3 окт 19, 11:00    [21985633]     Ответить | Цитировать Сообщить модератору
 Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?  [new]
FatumX
Member

Откуда: Минск
Сообщений: 61
посмотрел тут.Вариант интерестный. попробую.
https://www.techonthenet.com/sql_server/truncate.php

Мне бы еще аргументов, для это способа для разраба.
3 окт 19, 11:02    [21985635]     Ответить | Цитировать Сообщить модератору
 Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?  [new]
FatumX
Member

Откуда: Минск
Сообщений: 61
Беда в том, что никто не знает сколько строк меняется и как. Я вижу только Одно условие. полная очистка данных перед импортом и как можно быстрее.
3 окт 19, 11:05    [21985638]     Ответить | Цитировать Сообщить модератору
 Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6788
FatumX,

это мышление прикладника... Удаление и создание объектов может привести к ряду нежелательных последствий, в том числе неоднозначность развертывания, управления правами, фрагментация данных из-за "дыр" от таблиц и т.д.

Компромиссом может быть truncate таблицы, но эта команда требуется ALTER разрешений на объект, что не всегда приемлемо.

По-хорошему же, CRM строится на Integration Services решении. Кроме того, убедитесь, что база данных разрабатывается в проекте Visual Studio, это сэкономит в дальнейшем много времени на использовании версионирования, выпуске релизов, развертывании и так далее.

Но, судя, по вопросу, уровень разработчика близок к кустарному. Уж извините за прямоту.
3 окт 19, 11:39    [21985664]     Ответить | Цитировать Сообщить модератору
 Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?  [new]
Андрей Юниор
Member

Откуда: Москва
Сообщений: 353
FatumX
Беда в том, что никто не знает сколько строк меняется и как. Я вижу только Одно условие. полная очистка данных перед импортом и как можно быстрее.

А зачем вообще такая таблица нужна? Для чего эти 10 млн строк?

Обычный рецепт: две таблицы. Одна таблица основная постоянная - с индексами, с ограничениями и другими "плюшками". Вторая: промежуточная постоянная, но перед выгрузкой новых данных транкейтиться, и любые индексы дропаются. После загрузки данных индексы создаются заново. Основная таблица обновляется MERGE.

Из достоинств: можно отслеживать изменения любым способом, блокировка основной таблицы по времени минимальна.

Если разницы между данными много, то MERGE будет дольше работать, чем TRUNCATE + BULK INSERT.
3 окт 19, 12:00    [21985692]     Ответить | Цитировать Сообщить модератору
 Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?  [new]
PavelPS
Member

Откуда: петербург
Сообщений: 84
FatumX,
можно дать разрешение на выполнение хранимой процедуры.

а табличка нужна в течении всего дня? может из неё удалять данные не перед вставкой, а раньше?
а что у вас за данные, что 10 млн строк это много?
3 окт 19, 12:19    [21985715]     Ответить | Цитировать Сообщить модератору
 Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?  [new]
uaggster
Member

Откуда:
Сообщений: 715
Создайте эту свою таблицу как in memory table с опцией sсhema stability, и ничего переделывать в логике приложения - будет не нужно.
3 окт 19, 12:31    [21985734]     Ответить | Цитировать Сообщить модератору
 Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?  [new]
uaggster
Member

Откуда:
Сообщений: 715
DURABILITY = SCHEMA_ONLY, конечно.

И импорт, заодно, будет раз эдак в дцать быстрее.
3 окт 19, 12:34    [21985741]     Ответить | Цитировать Сообщить модератору
 Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6612
uaggster
DURABILITY = SCHEMA_ONLY, конечно.

И импорт, заодно, будет раз эдак в дцать быстрее.

ну тут смотря что дальше с ней делают, inmemory по прежнему в сторону только oltp. Больше всего нравиться NoParallelForDmlOnMemoryOptimizedTable что убивает абсолютно все радости от inmemory
3 окт 19, 12:37    [21985747]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить