Какую систему баз данных использовать? (EAV с FK?)

Question

Я работаю над приложением, и мне было интересно, какая база данных будет лучше для меня.

Я пытаюсь смоделировать списки, но атрибуты / структура меняются в зависимости от локали. Я хотел бы сравнить, искать и т. Д. Эти списки / атрибуты по разным языковым структурам. Всегда есть возможность создать таблицу для каждой локали, но было бы неплохо сослаться на что-то вроде price = 100 вместо price_us = 100 OR price_de = 100 OR etc..

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

Есть ли что-нибудь, что дает мне такую ​​гибкость, но также что-то вроде ограничений FK? (ограничение определенными атрибутами или значениями?)

Answer 1

Хорошо .. я бы сказал что-то вроде:

Products           Locales              Prices
----               -----------          -----------
product_id PK      locale_id PK         product_id FK
name               title                locale_id FK
descriptions                            amount
                          if needed >>  currency_id FK     

Похоже на разумную структуру.Для таблицы Prices значение PRIMARY KEY будет составным.

Что касается выбора продукта со всеми данными:

SELECT
    Procucts.product_id
    Products.name
    Price.amount
FROM Products
    LFFT JOIN Prices USING(price_id)
    LEFT JOIN Locales USING(locale_id)
WHERE Locale.title = 'uk'

Answer 2

Моделирование EAV считается антишаблоном sql и по множеству веских причин, хотя оно является работоспособным и довольно распространенным в определенных секторах, например, в клинических системах.Однако это противоречит ряду принципов, на которых основаны реляционные базы данных (отсюда и термин «анти-шаблон»), и добавляет сложности / накладные расходы к запросам, в то же время затрудняя поддержание реляционного контекста данных.

Возможно,Несколько лет назад не было иного выбора, кроме как реализовать этот шаблон в MySQL, и я действительно работал над системой, которая выбрала этот подход.Однако 12 месяцев назад мы перешли на бэкэнд без схемы (mongoDB), который естественным образом подходит для хранения записей с переменными атрибутами.

IMHO - Если вы планируете реализовать шаблон EAV в MySQL, рассмотрите архитектуру БД без схемыпервый.