Какая структура базы, у товара с разными характеристиками и ценами этих характеристик?

abmanimenja, уважаемый собеседник, вопрос производительности выходит за рамки нашего диалога и уж тем более этого вопроса. Нормализованная база данных и высокая производительность стоят по разные стороны реки и зачастую принудительная денормализация лишь и спасает. Но опять же, это все выходит за рамки нашего диалога, мы говорили о правильной структуре и подходе к решению задачи "сущность с атрибутами", я Вам привел примеры правильных и неправильных решений в контексте реализации одной модели и искренне надеюсь, что Вы правда поняли эти примеры и узнали для себя что-то новое и интересное. Я ни в коем случае не отношусь к тем гражданам на айти площадках, которые уперто несут дичь до последнего лишь бы их эго не пошатнулось от того, что они великие могли чего-то не знать. Наоборот, всегда открыт к диалогам и обсуждениям и всегда с удовольствием черпаю для себя информацию и делюсь той, которая известна мне. Что же касается нормализации - последний раз я с нормализованными базами имел дело лет 8 назад и мне прекрасно известно, какой ценой достигается производительность) Но опять же - речь была о правильной структуре, поэтому я говорил о правильной структуре с точки зрения канонов. В общем, добра)

Какая структура базы, у товара с разными характеристиками и ценами этих характеристик?

abmanimenja, попробую максимально упрощенно чтобы как можно более наглядно:

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

Фактическая реализация данной модели может иметь множество вариантов. Как я и говорил, далеко не все воплощения этой модели являются правильными и уместными, а некоторые из них и вовсе неприемлемыми.

Пример неправильного воплощения/реализации Вы можете увидеть на первом скриншоте который я скидывал: там eav воплощен в виде таблицы вида сущность-атрибут-значение(в примере из книги это issue_id(сущность)-attr_name(атрибут)-attr_value(значение)). Такая реализация является крайне плохой, потому что приходится хранить все значения в виде строк, в том числе числа с датами, и все в одном столбце. При таком подходе мы не знаем типов значений, не можем вводить необходимости уникальности значений для определенных атрибутов и прочие вытекающие, то есть ни о какой целостности данных не может быть речи.

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

Еще один пример правильной реализации это создание для каждого подтипа отдельной таблицы. Этот подход хорош тем что сохраняются все преимущества реляционных СУБД, но уместно применим только когда количество подтипов не слишком большое. Вот описание подхода из этой же книги:



Это и есть те самые разные подходы, правильные и неправильные, где-то больше уместные где-то меньше, о которых я говорил.

UPD: пример плохой реализации о которой я говорил можете увидеть в ответе ниже пользователя alex-1917 на втором скриншоте, там как раз создана эта одна табличка где все хранится в виде строк(product_options_values)

Какая структура базы, у товара с разными характеристиками и ценами этих характеристик?

abmanimenja, я готов дискутировать.
Вот фрагмент из книги "SQL Antipatterns: Avoiding the Pitfalls of Database Programming", который иллюстрирует плохую реализацию eav, которая для Вас "не eav":


Из этой же книги, из этого же раздела, целиком посвященного EAV, что вы тоже назвали "нe eav":


Рекомендую к прочтению, очень хорошо разжеван EAV со всеми своими плюсами и минусами.

Надеюсь на конструктив с Вашей стороны.

Какая структура базы, у товара с разными характеристиками и ценами этих характеристик?

abmanimenja, в удаленном ответе все было более чем по существу(успел застать). А то, что Вы не увидели в тех примерах EAV, свидетельствует о пробелах в Ваших знаниях.

Какая структура базы, у товара с разными характеристиками и ценами этих характеристик?

Вам тут могут посоветовать структуру EAV.
Она действительно универсальна. Но довольно медленная при выборке данных и этот совет будет только от малограмотного разработчика.

Держите в курсе.

EAV можно реализовать совершенно по-разному. Есть отвратительные реализации этой модели, которыми грешат многие разработчики, которые сводят на нет все преимущества реляционных СУБД. Но есть и правильные подходы, которые во многом зависят от предметной области.

Если делать по уму, то вам нужен не реляционная PostgreSQL

Тостер не место для холиваров, человек задал вопрос как решить задачу в контексте его стека, в данном случае это реляционная СУБД.

Какая структура базы, у товара с разными характеристиками и ценами этих характеристик?

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

Хороша ли сборка пк?

Жесткий диск-10TB SEAGATE BARRCUDA

Вы собираетесь свой собственный интернет хранить?

Оперативная память-ddr4 corsair vengeance led 32gb 3200mhz или hyperx

Зачем 32GB? Хоть одна игра у вас 16 хотя бы брала? Даже в 4к(хотя видяха для 4к не особо подходит) 16ГБ не забьет ни одна игруля(ну или может одна найдется во вселенной), не говоря о меньших разрешениях

Итого: берете 16ГБ озу и 3ТБ ЖД, на сэкономленные покупаете терабайтный ссд ну или видяху покруче

Как правильно хранить переписку в БД в данном случае?

TopMetaFizick_010, нет, таким образом вы получаете всю историю сообщений для какого-то пользователя. Допустим есть пользователь Вася и его id = 52. И допустим он написал Диме у которого id=105 сообщение. Тогда в таблицу попадает запись, где user_from_id=52(кто отправил - Вася), а user_to_id=105(кому отправили - Диме). А если Дима напишет Васе то запись будет выглядеть наоборот - user_from_id=105(кто отправил - Дима), а user_to_id=52(кому отправили - Васе). Так вот запрос, который я привел выше - если Вы в него подставите id Васи то есть 52, то он вернет все сообщения, где id=52 встречается среди отправителей("user_from_id = $id_пользователя") и все сообщения, где id=52 встречается среди получателей("user_to_id = $id_пользователя"), то есть вернет всю историю сообщений Васи

Где без проблем арендовать VPS или сервер в Нидерландах?

От себя еще добавлю vultr.com, года полтора назад перешел на него с digitalocean, потому что дешевле выходило, по крайней мере тогда

Как ПС относятся к справочникам/словарям?

Как ПС относятся к справочникам/словорям?

Как же это иронично, допустить орфографическую ошибку в слове "словарь")

Как использовать order by и group by одновременно?

СОРТИРОВАТЬ ПО USER_ID

При этом у вас в запросе

ORDER BY id

Почему запрос дублирует данные?

ellz, ну тогда будьте начеку ведь если такие туры появятся то будут дубли

Почему запрос дублирует данные?

ellz, ну в вашем последнем запросе вы снова джойните tours а не то, что я вам в ответе написал, вы же понимаете что если будет для одного отеля несколько туров то вы снова получите "дубли"?

Почему запрос дублирует данные?

ellz, я к сожалению не могу сказать насколько это правильно, потому что я не знаю в чем ваша цель, то есть что вы хотите получить? Если скажете тогда смогу прокомментировать

Почему запрос дублирует данные?

ellz, ну наверное потому что у вас разные комнаты с одинаковыми параметрами. Там нет дублей, вы просто выводите не все столбцы и вам кажется что это дубли. В select-e вместо конкретных столбцов напишите * чтобы вывести все столбцы и тогда увидите что это не дубли

Как спроэктировать "варианты продукта" в интернет-магазине?

sim3x, будь вы хотя бы на одну десятую столь же компетентным сколь вы напыщенны, то выглядели бы менее нелепым

Как сделать sql запрос из одной таблицы с условием из другой?

ArtyomPLAY, изменил запрос в своем ответе, посмотрите сейчас

Как сделать sql запрос из одной таблицы с условием из другой?

ArtyomPLAY, либо я не понимаю что вы хотите, либо вы не совсем понимаете о чем говорите.
Посты с "user_id = 8 и action_type = 1" являются подмножеством постов, у которых "authors_id = 8". То есть они уже содержатся в списке постов с authors_id = 8, а вы говорите я хочу вывести и те и другие, но другие уже содержатся в "тех", они уже вывелись.

Приведите простенький пример обеих таблиц и что из них должно вывестись, потому что так не очень понятно что Вам нужно

Какой выбрать СУБД для Node.js, MySQL или MongoDB?

Любые ORMки позволяют вам работать с базой без знаний

SQL синтаксиса

, так что не стоит бояться

Как находить доски объявлений других стран?

Название страны на английском + classified. Для Китая например "china classified"