DoNiFF
@DoNiFF
Backend Developer

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

Например, есть таблица products, в котором могут быть как и аккаунты Steam, так и телеграма, и у каждой категории товара будут свои характеристики, у Steam к примеру будет уровень, баланс и тд, а у телеграма - есть премиум или нет, так вот, можно ли такое создать на MySQL или для этого потрубется не реляционная бд по типу MongoDB
PS. Сначала хотел сделать отдельное поле в products, в котором будет хранится характеристика для разных товаров в виде json, но потом понял что при таком раскладе я не смогу сделать фильтрацию для товаров
  • Вопрос задан
  • 708 просмотров
Решения вопроса 1
@KingstonKMS
1. Если полей для разных типов не много, то можно сделать все в одной таблице. Но это, как написали, денормализованный вариант.
2. Отдельные связанные таблицы для хранения параметров разных типов оптимальный вариант с учётом возможного увеличения как параметров, так и типов аккаунтов.
3. Но вы можете и json хранить в базе, осуществлять поиск и индексацию, см. https://dev.mysql.com/doc/refman/8.0/en/json.html
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
AshBlade
@AshBlade
Просто хочу быть счастливым
Можно, даже несколькими способами:
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'ов), но таблица может стать большой слишком когда много типов аккаунтов будет
Ответ написан
@Akina
Сетевой и системный админ, SQL-программист.
В рамках реляционной СУБД для описанной схемы есть несколько принципиально разных подходов.

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

Использование MongoDB на описанном материале (буквально пара типов объектов) мне кажется не очень соответствующим решением. Хотя зависит от планируемого объёма данных.
Ответ написан
Комментировать
Adamos
@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, и оптимизировать их индексами по соответствующим таблицам. Более того - для конкретной платформы можно будет естественно добавить еще таблицы, если будут какие-то специализированные данные (даты чатов только в телеге, ачивки только в стиме...) и работать с ними обычными запросами, без извращений.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы