Лучший стандарт для данных БД пользовательских плагинов в 2021 году?

Разработка
1

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

Меня немного беспокоит, как лучше структурировать это с точки зрения эффективности базы данных. Когда пользователь находится на странице города, я буду отображать ленту с «экспертами-участниками» этого города. Если мне придется при каждой отрисовке страницы категории выполнять запрос ко всем пользователям, перебирать их пользовательские поля и хеш «экспертных городов», это, по-моему, будет довольно медленно, особенно по мере роста числа пользователей и городов.

Если бы я разрабатывал это в собственном приложении на Rails, эта проблема легко решалась бы с помощью таблиц соединений и отношений has_many :through между моделями. Меня интересует, какой подход рекомендуется для плагина, которому нужна таблица соединений. Казалось бы, создание собственных миграций и таблиц не приветствуется, и обычно лучше использовать либо пользовательские поля, либо PluginStore. Я пока не смог найти реальной документации по PluginStore, но сейчас активно изучаю этот вопрос.

Казалось бы, разумно спросить о «официально рекомендуемом Discourse подходе», прежде чем углубляться в какое-либо конкретное направление.

Спасибо :slight_smile:
Зак

2

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

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

3

Ах, ок, отлично. Рад, что я спросил. :wink: Есть ли рекомендуемый способ изменять основные модели из моего плагина?

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

Я нашел этот пост, но похоже, что он так и не получил ответа.

4

Вышеупомянутый плагин Poll содержит несколько примеров:

5

Отлично! Я так рада, что это возможно! Спасибо.