Как лучше хранить данные в таблице MySQL?
На самом деле я хочу сохранить базовые способности для игры. у меня есть два варианта: сохранить очень длинную строку, например: [{‘baseId’: 1, ‘baseName’: ‘xyz’}, {‘//’, ‘//’, ‘etc’}] или вторая опция заключается в том, чтобы сохранить эти типы записей в нескольких строках и столбцах. Или, если у кого-то есть лучший вариант сделать это, вы можете предложить мне и спасибо заранее. 🙂
Решение
Это типичный объект, ориентированный на проблему реляционного отображения.
Короче говоря, это зависит от легкости чтения и легкости написания.
Если вы считаете, что эти данные всегда будут извлекаться как единое целое и сохраняются как единое целое, вы можете использовать Тип данных MySQL JSON или даже типа varchar.
В противном случае сопоставьте поля с новой таблицей и сохраните в виде строк. Здесь вам может быть лучше, если одна строка представляет 1 объект, а не усложняет дальнейшее и расширяет поле до строк. Снова посмотрите, как ваш READ и WRITE варианты использования по отношению к частичной или полной сущности.
Затем следует рассмотреть модель программирования — какая модель делает ваш код простым и менее подверженным ошибкам.
Другим аспектом является эффективность хранения. Сколько записей будет существовать? Тип данных влияет на это, например. типы BLOB-объектов TINYTEXT и LONGTEXT
разные, когда дело доходит до хранения.
Все эти аскеты нужно учитывать.
Другие решения
Это распространенная проблема. Обычный ответ: «Используйте реляционную базу данных так, как она должна использоваться, с четко определенными столбцами и строками». То есть твой второй вариант.
Хранение сложного объекта JSON (или другого типа) в поле Можно быть разумной вещью, чтобы сделать. Тем не менее, вы должны быть уверены в следующем:
- Поле только извлекается для передачи обратно вызывающему приложению.
- Поле никогда не будет использоваться для фильтрации результатов.
- Компоненты поля никогда не понадобятся.
(Я могу добавить, что специально для JSON, третий может быть смягчен в самой последней версии MySQL благодаря поддержке JSON.)
Другими словами, поле представляет собой «черный ящик» или «BLOB-объект», который не имеет значения для базы данных.
Ваши значения могут показаться релевантными для хранения в базе данных. Моя реакция заключается в том, что вы должны проанализировать значения и сохранить их в более правильном реляционном формате.
Существует 3-й вариант. Вы храните элементы в нескольких таблицах.
Во-первых, ваш основной стол для самых основных деталей, которые будут у всех. В этом случае, вероятно, имя и несколько других битов.
Вторая таблица содержит список всех способностей, которые может иметь или не иметь каждый персонаж.
В 3-й таблице есть несколько строк для каждого персонажа, по одной на каждую способность, которая есть у конкретного персонажа.
Таким образом, детали могут быть проверены напрямую с использованием SQL, но если в будущем для определенных символов будут добавлены дополнительные возможности, нет необходимости вносить какие-либо изменения в таблицу, просто добавляя немного дополнительных данных.
detector