Я бы хранил каждый периодический реквизит в отдельной таблице вида

Реквизит(ДатаНачала, ДатаОкончания, IDРодителя, Значение)

Если ДатаОкончания не указана, значит ее или нет, или это ДатаНачала следующего значения минус 1 день (час/минута/секунда зависит от задач).

Например,
Клиент(Ид, НепериодическиеАтрибуты)
НДС(ДатаНачала, ДатаОкончания, ИдКлиента, Значение) - история работы клиентов с НДС (являлись плательщиками, не являлись).
Договора(ИдДоговора, ИдКлиента, ПрочиеАтрибуты) - история договоров (кто-то может сказать, что это не история, а простой справочник договоров, но я отвечу, что в данном случае это одно и то же, ведь договора тоже заключаются на временной шкале, значит имеет место история), в ПрочихАтрибутах я скрыл даты.
Почему мы не включаем все (!) атрибуты договоров сразу в справочник Клиентов? Потому что есть понятие нормализации, и мне даже в голову не приходит складывать все в одну таблицу. А разделяя отношения на более мелкие таблицы мы уходим от избыточности (в справочнике Клиентов лежат данные только о клиентах, записанные единожды и не повторяющиеся из кортежа в кортеж). Уж не знаю сколько милисекунд мы потеряем на соединениях, однако красота схемы заставит нас впасть в нирвану.

Почему бы я выбрал хранение каждого вида реквизита в отдельной таблице? Люблю порядок. Любая сущность реального мира должна быть представлена отдельной сущностью базы данных. И если я захочу выбрать НДС, то посмотрю нужное значение в таблице НДС. А вообще тут зависит от предметной области. Если периодических атрибутов слишком много, то возможно и правда удобнее хранить их в одной таблице, чтобы не загромождать схему, выставив предварительно в отношении признак ТипАтрибута (правда тогда надо будет еще сделать справочник ТипыАтрибутов, опять же чтобы избыточность не плодить).