Дизайн таблицы SQL. Должен ли я создать дочернюю таблицу для полей, которые принимают нулевые значения?

Question

Контекст : у меня есть таблица с 20 столбцами. В этой таблице есть записи, которые импортируются из файлов, а затем их необходимо обработать. Поэтому существует столбец с именем ProcessDateTime, чтобы пометить запись как обработанную или нет.

Эта таблица достигнет миллионов записей. Некоторые записи никогда не будут обработаны.

У меня есть несколько вопросов:

• Скажем, 95% записей будут помечены как обработанные. Должен ли я создать дочернюю таблицу для хранения этого ProcessedDateTime?
• Что если будет обработано только 50%? Должно ли это иметь какое-то значение для дизайна базы данных?
• Мы говорим только об одном столбце. Что делать, если они 5 или 6 столбцов в той же ситуации?
• Есть ли здесь какая-нибудь линия, которую нужно провести?

Спасибо

Edit: Когда я выбираю свои данные, я хочу, чтобы записи не обрабатывались и не были старше одного месяца. Итак, у меня будет поле даты, чтобы сообщить мне, когда они были вставлены.

Answer 1

Я не рекомендую разделять записи в отдельную таблицу - это только усложняет управление базой данных.

Когда вы проектируете базу данных, очень важным является то, что будет выполняться запросов , а не просто теоретические соображения. Я предполагаю, что вы хотите быстро получить доступ к строкам, где ProcessDateTime равно NULL.

Что вас беспокоит (в данном случае), так это то, что нужные вам строки будут тонко распределены по многим строкам. Это, в свою очередь, означает, что у вас есть много страниц данных в памяти, но большинство записей не будут интересны, потому что значение не NULL.

Базы данных имеют два других варианта решения этой проблемы: кластеризованные индексы и разделы (хотя они не поддерживаются всеми базами данных). Обе эти возможности требуют дополнительных затрат при обновлении значения NULL до значения, отличного от NULL - в основном запись должна «переключать» разделы / местоположение страницы данных.

Тем не менее, в некоторых случаях имеет смысл иметь таблицу необработанных строк, и они затем "архивируются" после обработки. Хотя функционально то же самое, описание проблемы отличается. В этом описании основное внимание уделяется необработанным строкам; после обработки они отправляются в архив, где, по-видимому, значения не будут изменены.