Я ищу информацию о том, что лучше для моей проблемы. Говоря абстрактно, мне нужно хранить множество взаимосвязей и расставлять приоритеты между размером базы данных, скоростью запросов и «простотой обслуживания». Настройка 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
.
. У меня были следующие идеи, и я надеюсь, что у других есть отзывы об этих или дополнительных подходах:
Одна реляционная модель CountryVendor
с двумя булевыми столбцами (в этом случае при желании Продукт все еще может отображаться, если соответствующий country_vendor
еще не существует; т.е. показывать, если !country_vendor&.allow
) .
Предположим ок. 200 стран, это будет означать ок. 2000 строк в начале и около 600 тыс. Строк, если фильтры были на месте для каждого из 3000 потенциальных Vendors
.
(Теоретически, если небытие трактуется как true
, я мог бы также установить до задачи rake, которая удаляет строки, которые равны false
для обеих функций, и, таким образом, имеет размер таблицы.)
Две реляционные модели CountryVendorF1
и CountryVendorF2
, каждая из которых имеет только одна логическая колонка. Не уверен, что это будет сильно отличаться, но я представляю это ближе к тому, как я думаю о пользовательском интерфейсе для настройки фильтров страны (не вдаваясь в подробности здесь).
Два JSON столбцов в таблице Vendors
, в которых будут храниться значения true / false для каждого Country
. (Возможно, со строкой кода ISO в качестве индекса для простоты.) Не будет тысяч новых строк, хотя размер БД будет по-прежнему расти, но запросы могут стать медленными.