Наилучший вариант хранения данных - при помощи пары дат -
дата начала, дата окончания действия.

Если использовать только одну дату, то значительно повышается сложность извлечения данных на определенную дату.

Я после некоторого анализа когда проектировалась наша биллинговая система выбрал именно вариант с двумя датами. Причем было два типа версионных таблиц -
1. Содержащие большое количество атрибутов, которые редко относительно изменяются. В этом случае в таблицу просто добавляются dton,dtoff и соответствующим образом оформляются все запросы, обращающиеся к этой таблице.
2. Содержащие атрибуты, которые часто меняются. И, кроме того, нужно знать индививдуально какой атрибут с какой по какую дату имеет/имел такое значение. В этом случае в таблице храниться код_атрибута, датаот, датапо, значение, ну и может какие то еще атрибуты как то кто и когда изменял и пр.

Такой же подход встречал в некоторых других серьезных коммерческих продуктах.

В принципе, все версионные данные желательно хранить в таблицах второго типа - получается более универсальнее и правильнее. Но возникают например трудности на уровне описания ER-диаграм БД - они получаются очень непоказательными.

Подумывал над созданием некой надстройки в БД для хранения всех версионных (кстате, думаю правильней их называть историческими) данных - например, завести таблицу, содержащую
1. код категории (к какой таблице принадлежали бы эти данные, будь они оформлены неисторическими),
2. код подраздела (код атрибута),
3 и 4. дата от, дата по,
5. значение (может быть серия значений разных типов, или применение каких-либо объектно-ориентированных возможностей БД для хранения значений разных типов).
6. Поля описывающие кто,
7. и когда менял

Далее завести определенный уровень абстракции операций над историческими данными - добавление, удаление, изменение. В принципе, у меня уже есть определенные наработки, но сейчас ломать всю систему под это уже тяжело. Версионные данные в нашей системе хранятся в таблицах типа 1 и 2, как описано выше.

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

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