Проблема с активной записью

Question

Предположим, у нас есть модель пользователя.И пользователь может планировать некоторые действия.Количество типов действий составляет около 50. Все действия имеют общие свойства, такие как start_time, end_time, user_id и т. Д. Но у каждого из них есть несколько уникальных свойств.

Теперь у нас есть каждое действие, живущее в своем собственномтаблица в БД.И именно поэтому у нас есть такие ужасные SQL-запросы, как

  SELECT * FROM `first_activities_table` WHERE (`first_activity`.`id` IN (17,18)) 
  SELECT * FROM `second_activities_table` WHERE (`second_activity`.`id` = 17)
  .....
  SELECT * FROM `n_activities_table` WHERE (`n_activity`.`id` = 44)

Около 50 запросов.Это ужасно.

Существуют разные способы решения этой проблемы.

1. Выберите тип действия с наибольшим количеством свойств, создайте таблицу «Действия» и используйте модель STI.Но так мы должны называть наши столбцы неудобным образом, и часто запись в этой таблице будет иметь некоторые поля NULL.
2. Также модель STI, но имеет столбцы, общие для всех типов действий, и некоторые столбцы BLOB-объектов с сериализациейсвойства.Но мы должны сделать некоторые поиски деятельности - может быть проблема.И сериализация довольно медленная.

Пожалуйста, помогите мне разобраться с этим.Возможно, у моей проблемы совсем другое решение, которое будет соответствовать моим потребностям.

Спасибо за помощь.

Answer 1

Разбейте свои действия на несколько таблиц и постройте их из нескольких моделей.

Например:

таблица Activity_types: Имя

активность за столом activity_type_id Идентификатор пользователя [общие поля]

таблица activity_details activity_id ключ значение

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

Вы потеряете простоту отдельной модели / таблицы для каждого действия, но вы получите унифицированную модель деятельности, в которую можно добавить несколько методов, облегчающих выборку «подробных» данных, возможно, перегрузку #method_missing? или что-то.

У вас все равно будет более одного набора запросов, но у вас не будет пятидесяти, в итоге получится что-то вроде:

выбрать * из действий, где user_id = 1; выберите * из типов деятельности, где идентификатор в (...) выберите * из Activity_Details, где Activity_id в (...)

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

Answer 2

Возможно, реляционная база данных не является идеальным решением здесь.

Посмотрите на документно-ориентированную базу данных , например Mongo DB .

Из Википедии:

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

Редактировать

Почему все монго ненавидят? Кто-нибудь объясните пожалуйста.

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

Существует 50 различных представлений для Activity. Они разделяют некоторые данные, но в основном поля для каждого типа будут разными. Большое количество различных видов деятельности подсказывает мне, что на самом деле нет определенного представления для вида деятельности. Поддержание базы данных с фиксированными столбцами для обработки нефиксированного набора данных будет болезненным.

Вторая возможность, упомянутая автором, заключается в том, что сериализация действий в данные BLOB-объектов является чрезвычайно неэффективной и незапрашиваемой версией базы данных на основе документов.

Не отказываясь от downvoters, я просто хочу самообразоваться!