stepplerussphinx_mvпропущено...
Вам странно видеть проиндексированные даты? А разбение (партиционирование) больших таблиц по атрибуту с датой (ввода, операции и т.п.) Вам увидеть будет не странно?

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

Имею систему онлайн-мониторинга.
Одна из ее частей - сбор/отображение агрегированных данных с группировкой по дате. Дата - часть ПК таблицы-агрегатора, на который ЕСТЬ ссылка в таблице фактов. Еще одна часть системы мониторинга - сбор/отображение (других) данных с группировкой по дате/времени. И дата/время ТОЖЕ часть ПК - и ТОЖЕ есть ссылка. Лепить ПК вместо дат/времени на суррогатах? "Спасибо, я лучше пешком постою" (с)
stepplerusИ коэффициентов никаких нет. Есть только веса и объемы.
Вы можете смеяться, но я вполне могу себе представить задачу, когда пользователю ЗАПРЕЩЕНО указывать ВЕС (или ОБЪЕМ) чего-либо, не выбрав его (вес/объем) из справочника. Ограничение внешнего ключа без соответствующего индекса (по весу/объему) - очень больно даже на не очень больших объемах данных...
stepplerusИ причем тут партиционирование? Тем более, что в этой конкретной таблице 10 000 записей. Чего там партиционировать?Потому, что это только в ВАШЕМ случае - и ВЫ сделали вывод о каком-то "всегданеправильном" (мне так показалось?) использовании даты в качестве ПК.
Когда-то мне пришлось решать задачу разделения данных в базе на сервере, который поддерживал только партиционированные представления (MSSQL2000). Несколько одинаковых по структуре таблиц объединяются по union all в модифицируемое представление (без использования всяких дополнительных хранимых процедур и тригеров).
В составной ПК каждой из таблиц, учатвующих в партицировании, пришлось включить дату с CHECK констрайнтом по границам периода.

stepplerussphinx_mv,

Боюсь, что мы о разном.

Я вот о чем.
Есть таблица. В ней есть поле "Дата". В логической схеме. В физической - дата лежит в отдельной таблице, и имеет первичный ключ. И в "прикладной" таблице лежит именно это первичный ключ, а не дата.
При этом, если нужно изменить дату, ни в коем случае нельзя редактировать именно дату. Нужно либо создать либо выбрать дату из таблицы дат, а в прикладной таблице поменять значение внешнего ключа на новое.У Вас дата в этой таблице уникальна?
Если да, то кто (или что) запрещает ее использовать в качестве первичного ключа (в таблице с датами) и на нее же сделать внешний ключ в "прикладной" таблице? Религиозные соображения?
А по сути - реализуются те же ограничения с меньшими затратами. И вменяемость схемы становится по-лучше.
Бритва Оккама: не следует множить сущее без необходимости. В Вашем примере - явное тому нарушение.
stepplerusЗачем так делать? Какая от этого выгода? Назовите мне применения, которые не реализуются способом более простым, чем этот.
Не говоря уже о выбрке из такой таблице для диапазона дат. В данном конкретном случае - послать куда подальше суррогат и использовать ПК по дате. Более простого и более выгодного способа не существует. То есть, ВООБЩЕ!.. Заодно и диапазоны дат начнут обрабатываться со свистом... Если проиндексировать не забыли - по этому пункту имею обоснованные сомнения...
stepplerusЕсть вариант экномнее full-scan?Пугать меня фуллсканом - сугубо бесполезное дело.
Ибо фуллскан не всегда можно избежать. Если ВСЕ ваши запросы начинают и заканчиваются с него, то, не вдаваясь в кривизну дизайна, нужно либо переписываются запросы, либо добавлять индексы, а еще лучше - и то, и другое... И не забывать статистику собирать.
Есть таблицы на десятки миллионов записей. Подавляющее количество запросов к ним включают в себя сложную комбинацию соединений и условий, но - что характерно! - фулл-скан не наблюдаю. Что я делаю не так?