Приветствую.
Возможно, такие вопросы на форуме уже обсуждались, но найти не смог. По этому прошу или же ответить именно на мой, или же дать ссылку.
Проблема в следующем...
Сейчас формируется большая система статистики. Состоит она в сборе информации от клиентов компании. Изначально будем пробовать на нескольких клиентах, но уже к лету эта цифра перевалит за тысячу.
Приблизительная иерархия следующая:
Статистика идет по ПОДобъектам. Объекты и клиенты условно можно назвать фиксированными величинами. Каждый ПОДобъект в сутки генерирует 60 * 24 = 1440 записей - подробная поминутная статистика. У каждого клиента может быть много ~(1 .. 50) объектов, у каждого объекта ~(1 .. 10) ПОДобъектов. Таким образом, имея, к примеру, 50 клиентов с 5 объектами и 5 подобъектами, мы получаем в сутки 50 * 5 * 5 * 1024 = 1,280,000 записей в сутки. Пусть даже половина из них будут во внерабочее время (нулевыми) - т.е. их можно будет удалить. Но все равно - темпы роста большие.
Т.к. это статистика, то по ней придется делать много простых и сложных отчетов - необходима высокая скорость работы. Опустим на данный момент железо - будет неплохой двухпроцессорный сервер. Вопрос в том как лучше хранить данные?

Все хранить в одной таблице с указанием ClientID?
Таблица будет расти с огромной скоростью. Выборка будет занимать слишком много времени.

Создавать для каждого клиента свою таблицу?
Да, записей в каждой значительно меньше и запросы становятся проще и быстрее. Однако можно забыть о плюсах хранимых процедур - придется использовать динамический SQL. Кроме того, когда на сервере будет порядка 1000 таблиц с имена вроде Stat1, Stat2, ... - не самое это правильное решение.

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

Прошу помочь в данном вопросе. Спасибо.

>А почему бы не использовать MS Analisys service?
Поподробней, пожалуйста.

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

авторА вот "неплохой ДВУХПРОЦЕССОРНЫЙ сервер" для 1.3 млн записей в сутки - это ...интересно...
:) согласен, что это немного, но для начала пойдет.
ПРошу исходить из данных на текущий момент.
Еще раз... КАК лучше хранить статистику?

Вопрос в том как хранить?
Статистика идет по каждому ПОДобъекту.
У нас пока два варианта - или со всех клиентов хранить в одной таблице, или же в разных, или же..... что-то еще.

Уважаемые, никакой мусорной кучи нет.
Хранят данные, я не спорю. не в том дело.
Проблема в том КАК их хранить?
Отчеты могут быть любые. С любой дискретизацией за любой период.
Сводных таблиц столько, сколько отчетов, не создашь.
Весь этот вопрос я задал только по той причине, что очень большой объем данных. Как строит базы я знаю. Хотелось именно получить совет как поступать в данной ситуации.

Большое спасибо за ответы.
Полностью согласен по поводу наиболее часто используемых отчетов и выноса их в отдельные таблицы. Но все-таки исходные данные с дискретностью в минуту как нам лучше хранить?

Вполне понятно. Вы сейчас говорите о сводных таблицах. Т.е. таблицах с меньшей дискретизацией. Они - это отдельный разговор. Понятно, что их будет необходимо создавать. Но. Исходные то данные все равно нужно как-то хранить. Еще идея поступила хранить исходные данные по месяцам в разных таблицах.

gardenmanЕсли иерархия состоит всего лишь из 3 уровней, то полчается всего лишь 4 таблицы. Клиенты, Объекты,Подобъекты, Статистические по подобъектам.
Причем первые три будут относительно маленькими. А четвертую можно секционировать. А сводные таблицы - отдельная история.
Именно так. о чем я и говорил с самого начала.

2Титов Александр: Представим себе, что через некоторое время будем 50 млн записей. Сколько будет идти поиск определенной записи по такой таблице? Думаю, что очень долго.

Ок, всем огромное спасибо за ответы, обязательно учтем.
Как систему запустим - напишу, как чего сделали - может кому интересно будет.
Еще раз спасибо.