Ипатьев, всё, что описывается как JSON - прекрасно ложится в JSON, в том числе и Collection и его потомки.
Возможно, вы предлагаете заморочиться, и слабзать нормализованную структуру в РСУБД. Но вопрос был - в другом.
Ну и если вы говорите, что так нельзя, потому что нарушается ссылочная целостность, то хорошей практикой дизайна БД является логическое удаление, а не физическое, особенно - если дело касается случая, описанного топик-стартером.
Я предлагаю понять, что заморочиться - это как раз JSON. В исключительных случаях. Ни один из которых к вопросу отношения не имеет. Но уже вижу, что бесполезно.
Смотри. Обычно реляционная алгебра рассматривает коллекции внутри ячеек как потенциальную проблему. Проблему денормализации. Если скин у тебя это сложный объект с другими свойствами и эти свойства вдруг (!) внезапно обрастают связями с другими сущностями БД - то тогда считается что БД плохо спроектирована. Невозможно отслеживать целостность. Или представь что какой-то скин ты решил удалить из системы. Тебе придется сделать поиск всех коллекций всех плееров и поискать его и удалить. И те-же проблемы с вставкой и обновлением.
Но если ты никогда этого не будешь делать и тебе плевать на реляционные связи от скинов к другим элементам системы - то тогда можешь хранить в JSON. MySQL его поддерживает в угоду современным трендами на NoSQL.
Хотя тема NoSQL - гораздо более обширная и сложная чем просто денормализация. Про нее можно говорить часами.
В начале всё правильно, а дальше ерунда.
JSON - это не "когда плевать" и не "в угоду", а когда у данных нет чёткой структуры.
То есть JSON-поле - это ячейка для нереляционных данных в реляционной БД
И говорить там часами просто не о чем. NoSQL в значении "основная БД приложения системы "как бог на душу положит" АКА MongoDB" - это просто бессмыслица, говорить там не о чем - ни часами, ни минутами.
Всё остальное же "NoSQL" - это совершенно разные, никак не связанные между собой служебные хранилища, типа key-value storage, кэшей, поисковых движков.
Простой
