Архитектура БД

Павел Сизько

Возникла необходимость организовать БД для хранения и последующего анализа большого количества данных. В связи с чем хочу проконсультироваться у знающих людей (если тут такие есть :D )
Ну вообще может кому еще полезно будет это обсуждение
Итак,

Есть некие объекты, состояние параметров которых нужно хранить в бд и + к этому, нужно хранить всю историю изменений этих объектов (для последующего анализа нужно будет знать, в какое время какие значения параметов были у этого объекта)

Для грубого примера представим, что эти объекты - пользователи.** (! далее я буду говорить о пользователях для понимания, но на самом деле данные у меня будут другие !)** Обычно их всех хранят в одной таблице. И тогда можно хранить их историю в этой же таблице. Например - пользователь изменил имя и какой то параметр - в таблицу записываем новое состояние пользователя на текущую дату. И того - у нас этот пользователь записан в таблице 2 раза, причем самый последний раз - это его актуальное состояние, а все остальные - его история. Пример набросал http://joxi.ru/eAOLM0Bu4DKl8r

Вроде бы все ОК.. Но если пользователей тысячи - десятки тысяч, а изменения в параметрах происходят по нескольку раз в день?

Тут уже кажется глупо писать все в одно место (или может я ошибаюсь?)

Я предполагаю, что в таких случаях используют что то вроде этого(?) :
хранят каждого пользователя в своей таблице, в которой уже хранятся все его состояния по времени
Пример: http://joxi.ru/Q2K54Dlt9q6YQr
Я правильно понимаю?

Если да, то как организуют хранение этой кучи из тысячей разных таблиц в бд?
И возможно ли в случае такой организации удобно использовать Active Records?

В общем вопросов много) Поделитесь реальным опытом. (догадки я могу и сам придумать себе)

Павел Сизько больше 1 года назадСпасибо 0
1 чел.