Вопрос по архитектуре.

Нужно : организовать структуру данных, чтобы можно было откладывать (шедулировать) некоторые данные. То есть чтобы до определенного момента времени таких данных не было в выборке.

Критерии
1. Не должно быть огромной вложенности. То есть средняя расширяемость.
2. Само собой быстрота.

Дано (реальные данные)
1. Таблица с данными (Data). У нее есть ключи на тип данных (DataType), статус данных (DataState - обработано/необработано/...), оператора (Operator), клиента (Clients). Оператор относится к определенному отделу (Department). Отделы связаны между собой через фирмы (Firms).
Соответственно оператор обрабатывает данные и может видеть как по своему отделу, так и по фирме все данные (то есть других отделов).
Отсюда можно сделать некоторый вывод о том, как примерно может быть нелегко уже базе. Конечно это лишь 1% от всего что есть в БД.

Мои идеи
1. Минимальная расширяемость - два поля в таблице с данными - DelayDate, DelayState
2. Средняя расширяемость - доп таблица DelayedData в которой ключ на DataId, с временем и статусом. И далее два варианта:
а) Удалять из таблицы по какому то джобу или иному действию: where DelayDate < getdate()
б) Не удалять, но менять статус.
Соответственно типы запросов от этого поменяются с exists(...) на (... where DelayState = ....)
3. Пока не придумал.

На текущем этапе задачи не понятно, будет ли дальнейшее развитие.

Хочу послушать ваши предложения и услышать критику на ваши варианты. Спасибо.

Дополню, чтобы не было про вьюхи - вся логика в процедурах. Селектов напрямую нет.
Планы кешируются соответственно.

Спасибо за идею про вью спасибо.

Про visible - тоже. Но раз в три часа или в час или в полчаса... это специфично, потому что а если отложено будет на 10 минут...

Это я рассуждаю. С чего то надо начать.