Какова соответствующая индексная архитектура, когда она вынуждена реализовать IsDeleted (мягкое удаление)? - PullRequest
0 голосов
/ 16 апреля 2019

В настоящее время у нас есть база данных и приложение, которое полностью функционально.У меня нет возможности изменить архитектуру на этом этапе.Сегодня каждая таблица в базе данных имеет поле «IsDeleted» NOT NULL BIT со значением по умолчанию «0».Когда приложение «удаляет» данные, оно просто обновляет флаг IsDeleted до 1.

Мне трудно понять, как должны быть структурированы индексы для каждой из таблиц.Прямо сейчас каждый запрос / соединение / и т. Д. Всегда реализует проверку IsDeleted.Это стандарт, которому должны следовать наши разработчики.При этом я пытаюсь определить, нужно ли изменить все мои кластерные индексы первичного ключа в каждой из таблиц, чтобы включить первичный ключ И поле IsDeleted BIT.Кроме того, так как каждый запрос / присоединиться / и т.д.должен реализовать проверку IsDeleted, является ли это правильным предположением, что КАЖДЫЙ ОДИНОЧНЫЙ индекс (также некластеризованный) должен включать поле IsDeleted в качестве первого поля индекса?

Еще один вопрос, который у меня есть, касается отфильтрованных индексов,Я понимаю, что я мог бы поместить фильтры в индексы, такие как "WHERE IsDeleted = 0", чтобы уменьшить размер индексов.Однако, поскольку в каждом соединении / запросе должна быть реализована проверка IsDeleted, будет ли это препятствовать использованию отфильтрованного индекса (поскольку столбец IsDeleted используется в соединении / запросе)?

Помните, у меня нетвозможность изменить подход IsDeleted.

...