Rails & Postgres: лучшая практика для многих записей логических отношений - PullRequest
1 голос
/ 27 января 2020

Я ищу информацию о том, что лучше для моей проблемы. Говоря абстрактно, мне нужно хранить множество взаимосвязей и расставлять приоритеты между размером базы данных, скоростью запросов и «простотой обслуживания». Настройка Ruby на Rails с PostgreSQL.

Более подробное описание c: Представьте себе веб-сайт с базой данных Products, доступной для поиска и продаваемый Vendors. Vendors может не отправляться по всему миру, и я хочу отфильтровать Products по поставщикам, которые не будут отправлять пользователю в зависимости от их страны GeoIP. Чтобы немного усложнить задачу, страница Product может иметь две разные функции (назовем их F1 и F2), которые зависят от гео-IP.

Пример: A Vendor может захотеть, чтобы их Product страницы имели функцию F1 для всех стран мира, кроме нескольких, например, из-за эмбарго; но функция F2 может быть доступна только для стран, например, в Европе.

Фильтры стран всегда будут установлены на уровне Vendor.

Функция «поиска» на сайте является основной c SQL поиск, в котором я хочу, чтобы Products отображался, если хотя бы одна из функций доступна для страны текущего пользователя.

Веб-сайт будет разрешен в диапазоне от 1000 до 3000 Vendors (это жесткий предел), и в общей сложности от 10 000 до 50 000 Products. Давайте предположим, что в начале фильтрация имеет отношение только к 100 Vendors.

. У меня были следующие идеи, и я надеюсь, что у других есть отзывы об этих или дополнительных подходах:

  1. Одна реляционная модель CountryVendor с двумя булевыми столбцами (в этом случае при желании Продукт все еще может отображаться, если соответствующий country_vendor еще не существует; т.е. показывать, если !country_vendor&.allow) .

    Предположим ок. 200 стран, это будет означать ок. 2000 строк в начале и около 600 тыс. Строк, если фильтры были на месте для каждого из 3000 потенциальных Vendors.

    (Теоретически, если небытие трактуется как true, я мог бы также установить до задачи rake, которая удаляет строки, которые равны false для обеих функций, и, таким образом, имеет размер таблицы.)

  2. Две реляционные модели CountryVendorF1 и CountryVendorF2, каждая из которых имеет только одна логическая колонка. Не уверен, что это будет сильно отличаться, но я представляю это ближе к тому, как я думаю о пользовательском интерфейсе для настройки фильтров страны (не вдаваясь в подробности здесь).

  3. Два JSON столбцов в таблице Vendors, в которых будут храниться значения true / false для каждого Country. (Возможно, со строкой кода ISO в качестве индекса для простоты.) Не будет тысяч новых строк, хотя размер БД будет по-прежнему расти, но запросы могут стать медленными.

...