Можно ли такое реализовать с помощью MySQL?

Question

[DoNiFF]

Например, есть таблица products, в котором могут быть как и аккаунты Steam, так и телеграма, и у каждой категории товара будут свои характеристики, у Steam к примеру будет уровень, баланс и тд, а у телеграма - есть премиум или нет, так вот, можно ли такое создать на MySQL или для этого потрубется не реляционная бд по типу MongoDB
PS. Сначала хотел сделать отдельное поле в products, в котором будет хранится характеристика для разных товаров в виде json, но потом понял что при таком раскладе я не смогу сделать фильтрацию для товаров

Answer 1

[Sergey]

1. Если полей для разных типов не много, то можно сделать все в одной таблице. Но это, как написали, денормализованный вариант.
2. Отдельные связанные таблицы для хранения параметров разных типов оптимальный вариант с учётом возможного увеличения как параметров, так и типов аккаунтов.
3. Но вы можете и json хранить в базе, осуществлять поиск и индексацию, см. https://dev.mysql.com/doc/refman/8.0/en/json.html

Comments

[Akina]

Но это, как написали, денормализованный.

Ну и неправильно написали. Нет там ничего денормализованного. Обычная себе разреженная таблица.

[DoNiFF]

Спасибо, оказывается все таки возможно по параметрам jsonа делать фильтрацию

[Akina]

Pro_Hacker, угу, можно... но в MySQL это либо стопицот функциональных индексов, либо фуллскан.

Answer 2

[Сергей Соловьев]

Можно, даже несколькими способами:
1. Отдельные таблицы с характеристиками по каждому аккаунту. Например, для стима типа

create table product_steam_info(product_id int, level int, balance double)

и для телеги соответственно.
Чтобы получить результат полный - SELECT с JOIN'ом (left join нужен будет)
2. Все в одной таблице хранишь

create table products(product_id int, steam_level int, telegram_is_premium boolean)

Если у кого-то нет телеги или стима, то эти поля просто будут null

Предлагаю использовать последний вариант, т.к. его проще реализовать и будет быстрее (т.к. локальность данных больше и нет join'ов), но таблица может стать большой слишком когда много типов аккаунтов будет

Comments

[DoNiFF]

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

[Дмитрий Беляев]

Pro_Hacker, насчет второго варианта, он ещё и денормализован, что не очень хорошо для реляционных БД, в том числе по той причине, что Вы описали.
А из реляционных БД принципиален именно MySQL? Просто в том же Postgres есть и jsonb поля с поиском и индексами по ним и кастомные типы и возможность сделать sequence (autoincrement) на несколько таблиц.

[Сергей Соловьев]

Дмитрий Беляев, предполагаю, что это де-факто стандарт для пхп - часто вижу, что вместе берут

[DoNiFF]

Дмитрий Беляев, Просто я сам только с MySQL работал, если он не очень труден в освоении, то можно

[Дмитрий Беляев]

Pro_Hacker, Postgres более строго относится к типам полей, все касты между типами явные, а самих типов больше. Ну и есть куча возможностей, без которых вполне можно обходиться, но когда изучишь - MySQL будет казаться обрубком СУБД, ИМХО.

[Akina]

Дмитрий Беляев,

насчет второго варианта, он ещё и денормализован

??? Почему? что тут денормализованного?

[Дмитрий Беляев]

??? Почему? что тут денормализованного?

Akina, данную сущность можно декомпозировать без потерь

[Akina]

Дмитрий Беляев, Я вижу:

create table products(product_id int, steam_level int, telegram_is_premium boolean)

product_id - внешняя ссылка, как я понимаю.
steam_level - ну... наверное, можно возможные значения вынести в отдельную таблицу, но как по мне, то оно не стоящее дело. Тогда уж CHECK constraint или вообще ENUM.
telegram_is_premium - тоже как-то выносить странненько.

Что декомпозировать-то?

[Дмитрий Беляев]

Akina, из исходного вопроса можно сделать вывод, что такой параметр не 1 на платформу

[Akina]

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

Answer 3

[Akina]

В рамках реляционной СУБД для описанной схемы есть несколько принципиально разных подходов.

Первый - одна таблица и NULL в полях, отсутствующих у конкретного типа, её описывает Сергей Соловьев, вариант 2.
Второй - использование EAV. Удобно, динамично, но проблемы с производительностью. Хотя из всех паттернов для реляционных СУБД он походу наиболее применим для фасетного поиска.
Третий - использование сериализованного формата хранения. Например, хранение свойств объекта в формате JSON. Но, поскольку требуется поиск по атрибутам, в этом случае необходимо будет использовать внешний поисковый движок, возможно, даже ориентированный на фасетный поиск, или будет ужас как медленно.

Использование MongoDB на описанном материале (буквально пара типов объектов) мне кажется не очень соответствующим решением. Хотя зависит от планируемого объёма данных.

Answer 4

[Adamos]

Если каждую платформу программист будет добавлять сам и полировать, можно выделить свойства аккаунтов в отдельные таблицы, собрав их общие поля в общую же таблицу:

CREATE TABLE `accounts` (
  `id` int(10) UNSIGNED NOT NULL,
  `user_id` int(10) UNSIGNED NOT NULL,
  `title` varchar(255) NOT NULL,
  `morph_id` int(11) NOT NULL,
  `morph_type` enum('skype', 'tg') NOT NULL
);

CREATE TABLE `skype_accounts` (
  `id` int(10) UNSIGNED NOT NULL,
  `login` varchar(255) NOT NULL,
  `info` varchar(255) NOT NULL
);

CREATE TABLE `tg_accounts` (
  `id` int(10) UNSIGNED NOT NULL,
  `number` varchar(255) NOT NULL,
  `chat_id` varchar(255) NOT NULL
);

Позволит составлять достаточно сложные запросы, не убивая базу работой с JSON, и оптимизировать их индексами по соответствующим таблицам. Более того - для конкретной платформы можно будет естественно добавить еще таблицы, если будут какие-то специализированные данные (даты чатов только в телеге, ачивки только в стиме...) и работать с ними обычными запросами, без извращений.