Хороший подход к планированию БД для службы отчетности

Question

Сценарий:

Большая система (~ 200 таблиц).
60 000 пользователей.
Сложные отчеты, которые потребуют от меня выполнения нескольких запросов для каждого отчета, и даже это будут сложные запросы свнутренние запросы повсюду + некоторая обработка в PHP.

Подход:

Я видел подход, в котором я не уверен:
Имею одну централизованную, ненормализованную таблицу, в которой регистрируется любая активность в системе, которая подлежит отчетности,Эта таблица будет содержать в основном внешние ключи, поэтому она должна быть достаточно компактной и быстрой.
Так, например (Моя система представляет собой систему управления виртуальным обучением), пользователь записывается на курс, таблица хранит идентификатор пользователя, дату,идентификатор курса, идентификатор организации, вид деятельности (зачисление).
Конечно, я также храню эти данные в нормализованной БД, которую использует реальное приложение.

Плюсы: просто, легко обслуживаемозапросы и код для обработки данных и быстрого поиска.
Минусы: существует опасность, что ненормализованная таблица будет не синхронизирована с реальной БД.

При таком подходестоит задуматься, или (желательно из опыта) это всего $ #% #% t?

Answer 1

Вам нужно создать хранилище данных вместо одной денормализованной таблицы. Поищите в Интернете информацию о звездной схеме, измерениях, уровнях, таблицах фактов. Или, что еще лучше, прочитайте эту книгу Инструментарий хранилища данных Ральфа Кимбалла Некоторые из них использовались примерно за 1,77 доллара США. Это фундаментальная книга по проектированию хранилищ данных - реальный совет.

Answer 2

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

Answer 3

Я использую тот же подход с вами прямо сейчас.

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

некоторые крупные компании (google, twitter, facebook) начинают покидать концепцию реляционных баз данных. они начинают использовать свою собственную концепцию базы данных с (может быть) таким большим количеством компонентов избыточности. но с другой стороны, их концепция приводит к простому и очень быстрому запросу.

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

С наилучшими пожеланиями