| Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
| Все форумы / Microsoft SQL Server |
  |
||
 хранимая процедура для пересоздания ограмной таблици. Может так не надо?
|
|
|
FatumX Member Откуда: Минск Сообщений: 61 |
Пишем приложение с БД. Разработчики придумали раз в сутки дропать таблицу и соответственно потом ее-же пере создавать уже пустой, для последующего импорта в нее очень большого объема данных(порядка 10 млн. строк) из некоего xml-файлика. Каждый день файлик новый. Простая очистка таблицы разработчику не нравится. Говорит уж очень медленно. Хочет использовать для этого хранимую процедуру, давать учетной записи приложения права на удаление и создание объектов в БД мне очень не хочется. Опять же удаление и пхание больших объемов одновременно, наверное приведет к диким тормозам. MS SQL server 2016. Хочу узнать мнение сообщества. |
| 3 окт 19, 10:53 [21985618] Ответить | Цитировать Сообщить модератору | |
| Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?
|
|||
|
mnbvcx Member Откуда: Сообщений: 220 |
TRUNCATE медленно?! |
||
| 3 окт 19, 10:56 [21985621] Ответить | Цитировать Сообщить модератору | |||
| Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?
|
|
|
FatumX Member Откуда: Минск Сообщений: 61 |
можешь пояснить. |
| 3 окт 19, 10:58 [21985625] Ответить | Цитировать Сообщить модератору | |
| Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?
|
|
|
teCa Member Откуда: Сообщений: 628 |
FatumX, Ну из всех видов очисток таблицы truncate, пожалуй, самый быстрый. Нужно понимать, как данные в этих 10млн строк ежедневно меняются. Если нужно вычистить 9999999 записей и оставить только одну, то пожалуй быстрее действительно сделать truncate и просто загружать данные заново. |
| 3 окт 19, 11:00 [21985633] Ответить | Цитировать Сообщить модератору | |
| Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?
|
|
|
FatumX Member Откуда: Минск Сообщений: 61 |
посмотрел тут.Вариант интерестный. попробую. https://www.techonthenet.com/sql_server/truncate.php Мне бы еще аргументов, для это способа для разраба. |
| 3 окт 19, 11:02 [21985635] Ответить | Цитировать Сообщить модератору | |
| Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?
|
|
|
FatumX Member Откуда: Минск Сообщений: 61 |
Беда в том, что никто не знает сколько строк меняется и как. Я вижу только Одно условие. полная очистка данных перед импортом и как можно быстрее. |
| 3 окт 19, 11:05 [21985638] Ответить | Цитировать Сообщить модератору | |
| Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?
|
|
|
Владислав Колосов Member Откуда: Сообщений: 7757 |
FatumX, это мышление прикладника... Удаление и создание объектов может привести к ряду нежелательных последствий, в том числе неоднозначность развертывания, управления правами, фрагментация данных из-за "дыр" от таблиц и т.д. Компромиссом может быть truncate таблицы, но эта команда требуется ALTER разрешений на объект, что не всегда приемлемо. По-хорошему же, CRM строится на Integration Services решении. Кроме того, убедитесь, что база данных разрабатывается в проекте Visual Studio, это сэкономит в дальнейшем много времени на использовании версионирования, выпуске релизов, развертывании и так далее. Но, судя, по вопросу, уровень разработчика близок к кустарному. Уж извините за прямоту. |
| 3 окт 19, 11:39 [21985664] Ответить | Цитировать Сообщить модератору | |
| Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?
|
|||
|
Андрей Юниор Member Откуда: Москва Сообщений: 522 |
А зачем вообще такая таблица нужна? Для чего эти 10 млн строк? Обычный рецепт: две таблицы. Одна таблица основная постоянная - с индексами, с ограничениями и другими "плюшками". Вторая: промежуточная постоянная, но перед выгрузкой новых данных транкейтиться, и любые индексы дропаются. После загрузки данных индексы создаются заново. Основная таблица обновляется MERGE. Из достоинств: можно отслеживать изменения любым способом, блокировка основной таблицы по времени минимальна. Если разницы между данными много, то MERGE будет дольше работать, чем TRUNCATE + BULK INSERT. |
||
| 3 окт 19, 12:00 [21985692] Ответить | Цитировать Сообщить модератору | |||
| Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?
|
|
|
PavelPS Member Откуда: петербург Сообщений: 84 |
FatumX, можно дать разрешение на выполнение хранимой процедуры. а табличка нужна в течении всего дня? может из неё удалять данные не перед вставкой, а раньше? а что у вас за данные, что 10 млн строк это много? |
| 3 окт 19, 12:19 [21985715] Ответить | Цитировать Сообщить модератору | |
| Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?
|
|
|
uaggster Member Откуда: Сообщений: 827 |
Создайте эту свою таблицу как in memory table с опцией sсhema stability, и ничего переделывать в логике приложения - будет не нужно. |
| 3 окт 19, 12:31 [21985734] Ответить | Цитировать Сообщить модератору | |
| Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?
|
|
|
uaggster Member Откуда: Сообщений: 827 |
DURABILITY = SCHEMA_ONLY, конечно. И импорт, заодно, будет раз эдак в дцать быстрее. |
| 3 окт 19, 12:34 [21985741] Ответить | Цитировать Сообщить модератору | |
| Re: хранимая процедура для пересоздания ограмной таблици. Может так не надо?
|
|||
|
TaPaK Member Откуда: Kiev Сообщений: 6801 |
ну тут смотря что дальше с ней делают, inmemory по прежнему в сторону только oltp. Больше всего нравиться NoParallelForDmlOnMemoryOptimizedTable что убивает абсолютно все радости от inmemory |
||
| 3 окт 19, 12:37 [21985747] Ответить | Цитировать Сообщить модератору | |||
| Все форумы / Microsoft SQL Server | |
|
x