Дизайн для базы данных

У меня есть 4 таблицы: users, posts, categories, categories_map

posts имеет id, text, category_id
categories_map содержит user_id и category_id

Моя цель - сделать очередь, которую пользователь может просмотреть. Кроме того, пользователь сможет пропустить некоторые сообщения или редактировать текст в них. Если пользователь пропустил сообщение, он никогда не появится в очереди. Однако пользователь не может изменить последовательность, потому что cron будет выполнять script.

Первый подход, я думаю, состоит в том, чтобы создать таблицу, которая будет содержать user_id, post_id, text_modified, is_skipped, last_posted. Поэтому, когда выполняется задание cron, он оставит временную метку, поэтому в следующий раз этот пост не будет схвачен, и пользователь легко сможет изменить текст для этого сообщения.

Второй подход заключается в создании отдельной таблицы, где очередь будет генерироваться для пользователя user_id, post_id, category_id, text_modified. Таким образом, задача cron может легко выполнить эту таблицу и удалить строку после ее завершения. Но при таком подходе, если у меня будет 30 пользователей, в среднем по 3 категории, каждая из которых содержит по 5000 должностей, моя таблица будет иметь уже 450000 строк. Да, если он правильно проиндексирован, все должно быть хорошо. Но будет ли он масштабируемым, если у меня будет 100-200 пользователей?

Какой подход мне пойти или есть ли другое решение?

Ответы

Ответ 1

Многое зависит от вашего продукта. Мы не знаем:

  • Как пользователи взаимодействуют друг с другом?
  • Должны ли сохраняться их действия (пропуски), или мы в порядке, если они теряют их выше 99,9 процентиля.
  • Являются ли их изменения текста на сообщениях, глобально видимыми или только для них.
  • Являются ли пользователи проверяющими сообщения по категориям?

Сказали все эти неизвестные, я возьму на него удар:

  • Если ответ на вопрос 4 ДА, то вариант № 2 выглядит более суровым, если судить по вашим ПК.
  • Если ответ на вопрос 4 НЕТ, тогда вариант №1 выглядит более суровым, если судить по вашим ПК.

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

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

  • Примечание. Вопрос 1 определит, насколько легко это было бы.

Сказав все это, помните о последствиях для работы:

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

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

  • Примечание. В зависимости от ответов на вопросы 2 и 3 вам может даже не понадобиться сохранять очереди.