Всем добра! Есть поле из 50 клеток. Пользователь может нажать только 4 клетки. Вопрос: Как лучше хранить в базе поле? Только 4 выбранных хранить или все 50? Если пользователей будет 100 по 50 клеток, то уже 5000 записей в базе. Можно ли иметь таблицу в БД с 50 полями? Тогда будет 1 запись = 1 пользователю. В каком случае будет нагрузка меньше? Спасибо!
полей будут два id content_json что на счет записи нажатых, либо овер 50 с нажатыми. Противоречие идет у тебя. Пользователь ограничен в 4 выборах --- Добавлено --- тогда 4 мона помимо ид, лол --- Добавлено --- но! если вздумается расширяться, - content_json
Дело даже не в расширении. Думал за json, его проблематично обрабатывать. Там массив вложенный и после нажатия одной клетки можно нажать только соседние и все. Т.е. придется высчитывать и делать запрет на другие. А если 50 полей в базе, то поставил 1 или ноль и делов
Задача не ясна, что за поле? клетки? переход/копание/огород? Карту или карты можно вообще отдельно хранить, а у пользователя хранить координаты, например.
Условие: "только 4 клетки" Правильное решение: хранить в БД 4-е значения (номер клетки пп). Т.е. в БД будет 4 поля. п.с. Если условие от ТП неточное или неполное, то правильное решение может быть другим.
Формулировка задачи - так себе)) Попробуйте двоичный формат хранения. Для матрицы - самое то) Строка 50 символов - 0 - это ненажатое, 1 - нажатое, и прям в varchar их ))) Правда выборку делать геморно)) зато компактно))) Или в json например так: {1:0,2:0,3:1,4:0,5:1,6:0......50:0} --- Добавлено --- ...еще есть вариант - как двоичное число в десятичном представлении Иногда это удобно Но для вашего случая наверное не вариант - 2 в 50 степени - это большое число)
Пять строк по 10 блоков (клеток) Как хотите так и называйте Залепил в базу 50 полей, занятое 1 (int) свободное 0 (int) Можно и матрицей и json и система координат, но у меня не так все сложно. Спасибо большое всем кто откликнулся!
"нажать"??? ))) При выборе типа поля надо сразу понять понадобится ли искать по этому значению в SQL запросе. Если нет, то это сильно упрощает выбор. Например, если это игровое поле в двумерной системе и его надо будет просто читать целиком, то тип TEXT или MEDIUMTEXT самое то. Создавать просто в текстовом редакторе и копи-пастить значение. Если это буквально четыре значения типа "номер поля" и по ним надо искать, то логично взять четыре поля INT/ Если это пятьдесят значений "да"/"нет" и по каждому из них надо искать - делай пятьдесят полей BOOL (MySQL их хранит как tinyint). С сериализованными значениями всё усложняется, не все диалекты и версии БД их поддерживают, поэтому если можно избежать такого, то лучше избежать. --- Добавлено --- Просто для развития, я не то чтобы советую использовать, в MySQL поддерживается тип поля "множество" : SET. Он как бы для нескольких вкл/выкл в одном поле ))) На самом деле сколько я видел примеров использования SET, он всегда вносил излишнюю сложность. Хотя в эпоху ORM и геттеров-сеттеров можно реализовать достаточно изящно.
На VPS заметил как то туго при импорте/экспорте ведет себя. На хостингах норм. Поэтому отказался от этого типа.