Лучшие практики по обновлению SQL-операторов для NCI dateKey в большой таблице фактов - PullRequest
0 голосов
/ 07 января 2019

У меня есть таблица фактов 55 Гб, где я должен удалить некоторые записи, которые позже можно будет вернуть обратно. Количество удаленных записей варьируется от 10 до 100 тыс.

В настоящее время моя стратегия удаления основана на этом: Я обновляю ключ dateKey для удаляемых записей, например, от положительного значения int 20080122 до отрицательного значения int -20080122, чтобы фильтры текущей даты не включали его.

Здесь я думаю, что вместо перемещения данных в таблицу фактов и обратно я делаю дату из диапазона дат фильтра, а затем перемещаю ее обратно в диапазон дат с возможностью фильтрации с помощью обновлений dateKey.

Мне бы хотелось услышать ваше мнение об этой стратегии удаления, особенно в отношении поведения NCI (некластеризованного индекса). Как вы думаете, обновление индексированного dateKey лучше, чем перемещение фактических данных?

1 Ответ

0 голосов
/ 07 января 2019

Вместо повторного назначения столбца dateKey наша стандартная практика заключается в добавлении в таблицу столбца «мягкого удаления», либо битового столбца «is_deleted», либо столбца «date_on» даты-времени, и использования этого столбца для фильтрации из "удаленных" строк.

Это требует больше работы с вашей стороны, поскольку все существующие запросы придется изменить, чтобы использовать этот новый столбец, но теперь вашей базе данных не нужно выполнять работу по повторной индексации или удалению / вставке фактических данных.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...