Нужен совет по структуре БД для больших объемов данных

[Alkinoy]

Нужен совет по структуре БД для больших объемов данных

Суть такая. Необходимо хранить историю об объектах.
Например - есть список людей. У человека есть свои данные - ФИО, дата и место рождения, должность и оклад. У них может меняться фамилия, должность, оклад... Надо иметь возможность выбора по конкретному человеку всей его истории с указанием времени изменения. При этом количество изменений велико (сотни миллионов).
Мое мнение: имеем таблицу, в которой храним текущее состояние человека. И таблицу, в которой храним все изменения, связь с первой по id человека. Если нужны данные о человеке - смотрим первую и выбираем историю о второй. Если необходимо найти какой то факт в истории - тогда уже теребим таблицу истории.
Да, в этом случае данные не нормализованы. Но вопрос в скорости работы - на первом месте, ибо объем большой.....
Кто что может сказать по теме? Прав я или нет?

 

[akd]

прав.

только насчет "сотни миллионов" меня терзают смутные сомнения ... или базу всех людей на евразии хранить собираемся?

 

[Alkinoy]

нет, сомнения зря мучают реальное количество записей перевалило за 300 млн. это ж не людей 300 млн, а записей - читай ИЗМЕНЕНИЙ в истории людей.....

 

[Фанат]

а часто у человека дата и место рождения меняются?

 

[Сергей Тарасов]

Хранить надо используя макисмальную нормальную форму.
Правда иногда приходится поступаться нормализацией ради скорости...

 

[Alkinoy]

Автор оригинала: Фанат
а часто у человека дата и место рождения меняются?

А я про изменения их и не говорил. к чему вопрос?

Автор оригинала: Сергей Тарасов
Хранить надо используя макисмальную нормальную форму.
Правда иногда приходится поступаться нормализацией ради скорости...

Вот я про оптимизацию по скорости и говорю.... я же сразу написал - мол понимаю, данные не нормализованы. Вопрос в другом - может есть другие предложения как хранить историю?

 

[Сергей Тарасов]

"ибо объем большой...."

Ну это понятие резиновое... Смотря что ты будешь хранить...
Какие нагрузки на систему... Какие запросы...
Просто цифра которую ты назвал 300 млн. записей - не такая уж большая... У меня столько в день набегает на статистике...

 

[Alkinoy]

Автор оригинала: Сергей Тарасов
"ибо объем большой...."

Ну это понятие резиновое... Смотря что ты будешь хранить...
Какие нагрузки на систему... Какие запросы...
Просто цифра которую ты назвал 300 млн. записей - не такая уж большая... У меня столько в день набегает на статистике...

Таки согласен.... думаю, только тест мне поможет точнее. Спасибо.
Кстати - а у вас какая субд? а какая структура таблицы статистики, которыз 300 млн в день? Интересно объем информации прикинуть......
К тому же с историей вопрос не просто хранить... эти данные потом используются в поиске, соединение с другими таблицами.....

 

[Сергей Тарасов]

Alkinoy
СУБД MySQL пятерка. Таблиц несколько... Раз в день все это хозяйство агрегируется хранимой процедурой....
По сабжу:
Да, нужно мерить, смотреть, какие поля... какой размер записи?
Почитайте любое руководство по оптимизации MYSQL, хотябы даже на их сайте... Количество записей - еще не критерий времени поиска в таблице!