2017-02-09 10 views
0

Обсуждались результаты работы SQL с коллегой и обсуждалась тема сохранения таблиц хранилища данных. Мой коллега (который намного более опытен, чем я) утверждает, что быстрее отбрасывать таблицу, воссоздавать ее и вставлять все свои записи, чем выполнять стандартные операции DML в таблице, когда происходят обновления данных. Будучи скептиком, я и мой предыдущий справочный фон (в R), кажется мне совершенно интуитивным для меня.Ванильные операции DML против DROP, RECREATE, (RE) INSERT - что более эффективно?

Отдельная запись составляет ок. 1,6 КБ, с распространением около ок. 50 столбцов. Количество записей зависит от одного бизнес-процесса, но размеры таблиц варьируются по размеру, причем наименьшее составляет около 25000 записей, а наибольшее - около 25000000. Типичные данные загружаются в таблицы ODS, см. От 0 до 500 записей, которые создаются или изменяются за таблицу в день.

Какой вариант является более производительным, сохраняя хорошо индексируется таблицы и используя операции ваниль DML (INSERT, UPDATE, DELETE) против двух операций DML (DROP TABLE, CREATE TABLE) с одной INSERT операции?

+1

'... распространение свыше ок. 50 столбцов .... 'Это не таблица базы данных. Это электронная таблица! – joop

+0

@joop действительно. Я слышу вас, но мы не можем контролировать объем этих таблиц ODS. Наши исходные системы имеют определенную модель данных (EAV), которые мы делаем для создания таблиц, подобных ODS, потому что попытка сделать оперативную отчетность по модели данных EAV является самоубийством. Если клиент настроил набор данных на 100 атрибутов, таблица будет иметь * k * + 100 столбцов, где * k * - некоторая константа (5, если я правильно помню). – Marley

ответ

-1

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

+0

Оператор truncate МИНИМАЛЬНО зарегистрирован. Общим убеждением является неправильное понимание, и его лучше не воспроизводить. Подробнее о заявлении TRUNCATE здесь: http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1930-truncate-table-is-non-logged/ –

+0

Да, ты прав. Я должен был быть более конкретным, когда я говорил о регистрации. Он не регистрирует отдельные строки, что дает большую экономию по сравнению с оператором удаления, особенно на большой таблице, и после его фиксации его невозможно восстановить. – kubasnack

 Смежные вопросы

  • Нет связанных вопросов^_^