У меня реализовано нечто похожее на предложенное Тигрой и Первым Андерсом

1. На каждую таблицу создается ее слепок (Customer -> CustomerHistory etc)
Она имеет все поля, как оригинальная, плюс ДВА новых: ValidFrom и ValidTo
PrimaryKey - identity, первичный ключ из оригинальной таблицы - кластерный во таблице истории, альтернативный ключ - первичный ключ из оригинальной таблицы плюс ValidFrom и ValidTo.
2. На оригинальной таблице пишем триггеры.
Вставка пишет в поле ValidFrom значение GETDATE(), а в ValidTo - 01/01/3000 (баг 3000 заложен в дизайне!)
Удаление записи вызывает делает следующее: для записи с тем же ключом, что в главной таблице, имеющей ValidTo равное 01/01/3000, ValidTo выставляется в GETDATE().
Изменение любого поля вызывает два действия: сначала алгоритм для удаления, а потом для вставки.

Таким образом, чтобы получить
текущее состояние, надо принести записи с ValidTo 01/01/3000
состояние на конкретную дату MyDate BETWEEN ValidFrom AND ValidTo

В моем проекте я поддерживаю историю для 10-и таблиц, нареканий по скорости не было. Правда, дата в них не меняется очень часто, экстремальных нагрузок не проверял. Задача была связать заказ с ценой заказа на момент его выполнения (под ценой подразумевается еще туча характеристик, которые невыгодно хранить в истории заказа). Запрос на миллионах заказов нареканий не вызывал.


Второе решение еще проще. Сходите на сайт www.apexsql.com, продукт ApexAudit, если не ошибаюсь