За последние 24 часа нас посетили 20266 программистов и 1080 роботов. Сейчас ищут 788 программистов ...

Как хранить такое поле в базе?

Тема в разделе "PHP для новичков", создана пользователем AlexProg, 3 май 2019.

  1. AlexProg

    AlexProg Активный пользователь

    С нами с:
    13 май 2014
    Сообщения:
    320
    Симпатии:
    7
    Всем добра!

    Есть поле из 50 клеток. Пользователь может нажать только 4 клетки.
    Вопрос: Как лучше хранить в базе поле? Только 4 выбранных хранить или все 50? Если пользователей будет 100 по 50 клеток, то уже 5000 записей в базе.

    Можно ли иметь таблицу в БД с 50 полями? Тогда будет 1 запись = 1 пользователю.
    В каком случае будет нагрузка меньше?

    Спасибо!
     
  2. MouseZver

    MouseZver Суперстар

    С нами с:
    1 апр 2013
    Сообщения:
    7.734
    Симпатии:
    1.315
    Адрес:
    Лень
    полей будут два
    id
    content_json

    что на счет записи нажатых, либо овер 50 с нажатыми. Противоречие идет у тебя. Пользователь ограничен в 4 выборах
    --- Добавлено ---
    тогда 4 мона помимо ид, лол
    --- Добавлено ---
    но! если вздумается расширяться, - content_json
     
    AlexProg нравится это.
  3. AlexProg

    AlexProg Активный пользователь

    С нами с:
    13 май 2014
    Сообщения:
    320
    Симпатии:
    7
    Дело даже не в расширении. Думал за json, его проблематично обрабатывать. Там массив вложенный и после нажатия одной клетки можно нажать только соседние и все. Т.е. придется высчитывать и делать запрет на другие.
    А если 50 полей в базе, то поставил 1 или ноль и делов
     
  4. lastdays

    lastdays Активный пользователь

    С нами с:
    27 сен 2012
    Сообщения:
    410
    Симпатии:
    74
    Задача не ясна, что за поле? клетки? переход/копание/огород?

    Карту или карты можно вообще отдельно хранить, а у пользователя хранить координаты, например.
     
    AlexProg нравится это.
  5. Chushkin

    Chushkin Активный пользователь

    С нами с:
    17 дек 2010
    Сообщения:
    1.062
    Симпатии:
    91
    Адрес:
    Мещёра, Центр, Болото N3
    Условие: "только 4 клетки"
    Правильное решение: хранить в БД 4-е значения (номер клетки пп).
    Т.е. в БД будет 4 поля.

    п.с. Если условие от ТП неточное или неполное, то правильное решение может быть другим.
     
    Vanchot и AlexProg нравится это.
  6. Roman __construct

    Roman __construct Активный пользователь

    С нами с:
    27 апр 2019
    Сообщения:
    1.270
    Симпатии:
    112
    Формулировка задачи - так себе))

    Попробуйте двоичный формат хранения. Для матрицы - самое то)

    Строка 50 символов - 0 - это ненажатое, 1 - нажатое, и прям в varchar их )))

    Правда выборку делать геморно)) зато компактно)))

    Или в json например так: {1:0,2:0,3:1,4:0,5:1,6:0......50:0}
    --- Добавлено ---
    ...еще есть вариант - как двоичное число в десятичном представлении

    Иногда это удобно

    Но для вашего случая наверное не вариант - 2 в 50 степени - это большое число)
     
    AlexProg нравится это.
  7. MouseZver

    MouseZver Суперстар

    С нами с:
    1 апр 2013
    Сообщения:
    7.734
    Симпатии:
    1.315
    Адрес:
    Лень
    :D Когда ночью не спится
    2019-05-04_02-07-27.png
     
    AlexProg и Roman __construct нравится это.
  8. MouseZver

    MouseZver Суперстар

    С нами с:
    1 апр 2013
    Сообщения:
    7.734
    Симпатии:
    1.315
    Адрес:
    Лень
  9. AlexProg

    AlexProg Активный пользователь

    С нами с:
    13 май 2014
    Сообщения:
    320
    Симпатии:
    7
    Пять строк по 10 блоков (клеток) Как хотите так и называйте :)

    Залепил в базу 50 полей, занятое 1 (int) свободное 0 (int)

    Можно и матрицей и json и система координат, но у меня не так все сложно.

    Спасибо большое всем кто откликнулся! :)
     
  10. artoodetoo

    artoodetoo Суперстар
    Команда форума Модератор

    С нами с:
    11 июн 2010
    Сообщения:
    11.068
    Симпатии:
    1.231
    Адрес:
    там-сям
    "нажать"??? )))

    При выборе типа поля надо сразу понять понадобится ли искать по этому значению в SQL запросе. Если нет, то это сильно упрощает выбор. Например, если это игровое поле в двумерной системе и его надо будет просто читать целиком, то тип TEXT или MEDIUMTEXT самое то. Создавать просто в текстовом редакторе и копи-пастить значение.

    Если это буквально четыре значения типа "номер поля" и по ним надо искать, то логично взять четыре поля INT/

    Если это пятьдесят значений "да"/"нет" и по каждому из них надо искать - делай пятьдесят полей BOOL (MySQL их хранит как tinyint).

    С сериализованными значениями всё усложняется, не все диалекты и версии БД их поддерживают, поэтому если можно избежать такого, то лучше избежать.


    --- Добавлено ---


    Просто для развития, я не то чтобы советую использовать, в MySQL поддерживается тип поля "множество" : SET. Он как бы для нескольких вкл/выкл в одном поле )))

    На самом деле сколько я видел примеров использования SET, он всегда вносил излишнюю сложность. Хотя в эпоху ORM и геттеров-сеттеров можно реализовать достаточно изящно.
     
  11. AlexProg

    AlexProg Активный пользователь

    С нами с:
    13 май 2014
    Сообщения:
    320
    Симпатии:
    7
    На VPS заметил как то туго при импорте/экспорте ведет себя. На хостингах норм. Поэтому отказался от этого типа.