Хороший подход к планированию БД для службы отчетов
Сценарий:
Большая система (~200 таблиц).
60 000 пользователей.
Сложные отчеты, которые потребуют от меня выполнения нескольких запросов для каждого отчета, и даже это будут сложные запросы с внутренними запросами повсюду + некоторая обработка в PHP.
Подход:
Я видел подход, в котором я не уверен:
Наличие одной централизованной, ненормализованной таблицы, в которой регистрируется любая деятельность в системе, подлежащая отчетности. Этот стол будет содержать в основном внешние ключи, поэтому она должна быть довольно компактной и быстрой.
Так, например (моя система - это виртуальная система управления обучением),
Пользователь записывается на курс, в таблице хранятся идентификатор пользователя, дата, идентификатор курса, идентификатор организации, тип деятельности (регистрация).
Конечно, я также храню эти данные в нормализованной базе данных, которую использует фактическое приложение.
Плюсы: простые, поддерживаемые запросы и код для обработки данных и быстрого извлечения.
Минусы: существует опасность ненормализованная таблица не синхронизирована с реальной базой данных.
Стоит ли рассматривать этот подход или (предпочтительно по опыту) всего $#%#%t?
3 answers
Вам нужно создать хранилище данных вместо одной денормализованной таблицы. Поищите в Интернете информацию о схеме звезды, измерениях, уровнях, таблицах фактов. Или еще лучше прочитайте эту книгу Набор инструментов для хранения данных Ральфа Кимбалла Некоторые из них использовались примерно за 1,77 доллара США. Это фундаментальная книга по дизайну хранилища данных - советы из реальной жизни.
Я использую тот же подход с вами прямо сейчас.
Некоторое время строго нормализованная база данных будет очень сильно замедлять запрос. а также его сложнее запрашивать. это очень верно, никто не может отрицать это условие.
Некоторые крупные компании (google, twitter, facebook) начинают отказываться от концепции реляционных баз данных. они начинают использовать свою собственную концепцию базы данных с (может быть) таким большим количеством компонентов избыточности. но, с другой стороны, их концепция приводит к легкому и очень быстрому запросу.
Я думайте, что ваш подход хорош, в то время как вы всегда можете гарантировать, что каждое изменение базы данных также будет проверяться на уровне приложения.
С наилучшими пожеланиями
Нормализация - это академическая концепция. Очень полезно, но бесполезно придерживаться его все время. Транзакции - это способ избежать несоответствий. Используйте избыточность, если она удовлетворяет вашим потребностям в более простом и эффективном запросе, например, у вас может быть одна таблица вместо 10+.