хочу оптимизировать таблицу и никак не могу допереть, что лучше всего подойдет для хранения числового перечисления ну хранить намерен примерно вот такую штуку 23246,72456,62468,46,676,0,0,0,0,0,0,0,0,0,0,0,687,657,0,0 всего по 20 переменных в ячейке, длинна каждой ячейки не более 6 цифр
139 символов и такие значения... ну хз... скорее всего будет varchar 139. лучше уже не станет. > всего по 20 переменных в ячейке, длинна каждой ячейки не более 6 цифр всего по 20 переменных в ячейке таблицы БД, длинна каждой как бы ячейки внутри перечисления не более 6 цифр
если эти данные не участвуют в условиях выборки, то их можно хранить как угодно. Насколько я понимаю, мускул возвращает в пхп строки всегда, даже если изначально там числа.
мускул хранит числа как числа. многие языки (не пхп) умеют получать из него сразу в своём нативном формате. типа взял int и в переменной уже int, а не строка. хз, как это происходит - по-честному (через получение мета-структуры ответа) или через спаренный запрос не знаю. но факт есть такой. так что вместо > мускул возвращает в пхп строки всегда всё же правильнее писать > пхп принимает из мускула все данные только в виде строк всегда
Да у меня jquery генерит такую штуку, и в принципе я хотел бы это заточить в условия выборки, ну чтобы обновляло только определённую ячейку, или бессмысленно и никакой оптимизации не принесёт?
апдейт 1 ячейки в строке, где 3 ячейки не быстрее, чем апдейт 1 ячейки в строке, где 100 ячеек. так что одно и то же получается. размер избыточной инфы в пакете что в одном, что во втором случае (6 символов против 139) несравним с объемом контента. т.е. считай, что ты служебную инфу туда-сюда гоняешь. нет смысла переписывать работающий код, чтобы получить то же, что и было - оставь как есть
Vantedur Если у тебя будет задача выбрать те строки, у которых самые большие значения в третьей переменной =) то ты не сможешь этого сделать просто-напросто. Если ты всегда заинтересован только в получении этих всех данных целиком - то пофик как хранить. а чем плохо сделать несколько полей?
Создаешь обыкновенную связь many-to-many, какие проблемы? Создаётся таблица для этих цифр, создаётся другая для хранения ключей и, соответственно, существует главная, в которой ссылаемся на связи. Всё. Ничего сложного тут не вижу, задача элементарнейшая.
many-to-many^ может я не до конца допёр но по мойму это даст термоядерную нагрузку, я думаю что должна быть какая-то адаптированная фишка для подобных задач типа spatial
Vantedur единственный вопрос, на который тебе надо ответить - это будут ли данные этого поля участвовать в запросах, как в том примере, который я тебе приводил.