Дело вот в чем:
Надо измерять перфоманс почасово и хранить агрегированную инфо чтоб кастомер мог потом пощупать это все.
Зачекать будем джамоном с аспектами, хранить, скорее всего, в рабочей схеме коре модуля, вопрос в айдихах/лейбелах.
(Ну и поминутно рассматривается на потом)

Айдиха видится примерно так:
"service1.getCustomer()." + "07.21.04.2012".
Вопрос во второй части, а именно дате. Брать календарик и писать час-день-месяц-год? Нарываться на таймзоны и дейлайт сдвиги?
Или брать карренттайм, отталкиваться от какой-то даты и считать "флаш чейпойнты" как частное от "(карренттайм-стартовая дата)/(1000мс*60сек*60мин)"?
А потом уже ковырять миллисекунды календарем при необходимости?




Это сообщение отредактировал(а) chief39 - 20.8.2012, 17:04

ИМХО, использовать timestamp будет правильно. Меньше проблем будет потом. А превратить его в дату всегда можно. 

Да, тоже склоняюсь к этому...

Еще задумался о том, чтоб лейблу разнести на два поля в БД:
Метка(плюс интервал - час, минута, етц) и таймстемп, который позволит быстро сортировать и выбирать диапазоны.
Если записей накопится over900 - выборка будет быстра и красива: ограничение по метке + between timestamp1 and timestamp2
С другой стороны - громоздко. Метку надо перманентно разбирать на саму лейбу, единицу измерения и таймстемп перед тем как лезть в базу.
Обобщенная метка "getCustomer().min.2345545450000" для рантайма и для БД упростит запрос при точечной выборке или выборке при предсформированном сете меток для IN, да и минус один индекс к тому же.

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


Это сообщение отредактировал(а) chief39 - 20.8.2012, 17:03

Лучше все-таки отдельно. Думаю быстрая выборка по интервалу окупит все дополнительные накладные расходы. Опять же если все правильно сделать в DAO, то эти накладные расходы будут только там. 

Да собственно это даже накладными расходами нельзя назвать, просто это реальность жизни.

Дело в том, что вставка в таблицу с почти миллионом записей будет происходить ежеминутно(ежечасово), а выборка - по необходимости(когда кастомер захочет взглядом Хрущева окинуть кукурузные поля, ну или когда нам понадобится получить какие-то приблизительные данные о конкретном затыке).
А регулярная вставка в миллионную таблицу с обновлением пары индексов - это все-таки вставка. 
Не исключаю варианта "давайте забацаем посекундную тарификацию ненадолго, механизм есть, а нам надо глянуть, поехали!". Тут уже дважды индекс будет играть роль 

Вы зря думаете что миллион записей это много. Для нормальной СУБД это не такая уж большая цифра.

Да приходилось как бы... 

Но этот функционал - побочен и должен быть as fast as possible 
Вставка то есть.
Выборка будет весьма редкой. Там уже не страшно будет и стянуть все что надо, а потом наверху разбирать.
Но отдельный таймстемп так и манит ))))

Переключаюсь на неделю на другой проект, вернусь и обязательно допишу что как.