Как записать массив в базу mysqli.
Всем привет! Запись везде почти происходит, но в 1-2 местах ни как. Вот приблизительный код(основной слишком большой чтобы приводить):
$arr13= array('100','93','94'); $StrSerialize= json_encode($arr13); mysqli_query($myConnect, "INSERT INTO `Fron` (id, Fron) VALUES ('{$str}', '{$StrSerialize}') "); в коде выше произошла начальное заполнение базы, с этим проблем нет точно и большая часть программы с такой базой работает, далее: читаем с базы: $arrFron= json_decode($arr[Fron]); изменяем данные (тут и начинаются проблемы, не с изменением, а с записью далее): $arrFron[]= strval($arrSmegnie2[$i9]); запись в базу: $StrSerialize= json_encode($arrFron); mysqli_query($myConnect, "UPDATE `{$Fron}` SET `Fron` = '{$StrSerialize}' WHERE `id` = '{$id}' LIMIT 1 "); Запись вообще не происходит, проблема в изменении данных, по идее все должно работать, я думаю касячные функции типа json_encode и Serialize, есть ли другие методы записи массива в базу? Не хочется писать свой json_encode. Данные записи-чтения: После начального заполнения базы имеем: ["94"] после изменения данных при последующей записи в базу имеем: ["94","100"] То есть перед конечной записью(та которая не работает) я проверяю что пишу и меня устраивает, так как ["94","100"] это то что нужно, но запись не происходит. Возможно там пробелы или спец символы, которые не видны, ни знаю почему не пишет. Скорее что-то происходит на стадии изменения данных, но там ни чего не должно происходить, так как я далеко не первый раз программирую и не представляю как более профессионально там написать код, там нет или почти нет вариантов. Вину валю на json_encode. Поле Fron имеет тип text. |
Что есть этот массив?
|
Цитата:
Обычный массив, имеет вид ["94","100"] или [94,100] - пробовал оба варианта, в этот массив происходит запись элемента ($arrSmegnie2[$i9]) другого массива, в свою очередь массив $arrSmegnie2 получен таким образом: $arrSmegnie2= $arrSmegnie; Массив $arrSmegnie является глобальной переменной, в которую происходит запись из функции, в функции имеем: $arrSmegnie[]= $arrSmegniePro[$i5]; Массив $arrSmegniePro получен через мою программу, эта программа выводит массив так: document.write(a); где а и есть массив $arrSmegniePro, просто с документа копированием берем строку массива и помещаем вручную в массив $arrSmegniePro. Ошибка может быть при копировании, может захватились пробелы или спец символы, но массив обрабатываю trim() и приведением к числу. Еще проблема может быть в $arrSmegnie2= $arrSmegnie; Но я ни знаю как проще переписать массив. В общем проблемы по идее не должно быть, но она есть - вообще не происходит запись в базу. |
Цитата:
|
Извиняюсь, но массивов у меня не один и разбирать зачем они нужны не имеет смысла, должен быть массив (нужен), по другому ни как, можно в отдельную таблицу, но это геморой. Какие веские основания? Для чего тогда сериализация или json существуют? Я правильно понял что массив лучше не пихать в одно поле? Как его тогда - в разные поля, какие есть варианты?
|
Странно однако суждение. К примеру идентификаторы заявок/заказов, это тоже массив. Как его нужно хранить в базе?
Нельзя в сериализованных данных сделать произвольную выборку, изменить их, и произвести другие прочие операции, которые составляют большую часть sql-запросов. Это можно сделать, но только посредством больших накладных расходов. А держать строку только потому, что ее можно извлечь, преобразовать, а затем сохранить, так это ведь тоже дополнительная нагрузка. В таком случае уж приложение, которое использует эти данные и должен их модифицировать, а sql только вставлять/обновлять. Что касается json_ecode, то она тут не причем, а то что в массиве могут быть пробелы, это не есть ошибка. |
Так я использую json_encode, вроде не работаю с сериализованными данными. Вообще нужно в одно поле запихнуть, сериализацией или строкой или иначе, мне пока все-равно, единственное что желательно - это возможность не вооруженным глазом видеть запись в базе, а не в бинарике к примеру. Так модификация данных и происходит в приложении php, как мне составить sql для поля в котором: 94,100 и что тогда в поле? Я думал что строка. Мне нужно удалить к примеру 94 или добавить 101. Наверное Вы имели в виду подобное: mysqli_query($myConnect, " UPDATE `red` SET `red` = CONCAT(`red`, ',' , '{$Log}') ");
С этого я начинал, работает еще хуже, мож запрос не правильный? |
База данных же не для того, чтобы в ней в РМА или подобном удобно было видеть все сразу и поэтому строка. Не важно сериализаиция или json, последняя ведь тоже строка.
Сравните, при значении как [94, 100], чтобы удалить 94 нужно извлечь, изменить, обновить. А если это записи, то DELETE/UPADATE WHERE field=94. Что эффективнее? Если уж строка, то ПО запросил данные -> отработал -> REPLACE или UPDATE. Но если с данными этого массива связаны данные, то хранение их как строка, это вообще самоубийство. |
Вот как Вы написали так и делаю, но в одном месте проги не работает, во всех остальных местах пока не выявил проблем. Стало быть скорее проблема в данных, а главное не способности mysqli съедать то, что дают, эта база очень капризная. С данными массива наверно связаны данные:
Делаю поиск, в том числе выбрав строку из базы, сделав массив, найдя значение в массиве, далее добавив другое значение в массив, далее массив в строку и в базу. Мне желательно хранить массив в одном поле, mysqli в этом плане плох? Почему самоубийство? Напишите пожалуйста полный код как хранить массив в одном поле, а также другие варианты хранения/изменения/записи массива. |
Проблемы в данных, вернее сказать в их преобразовании нет. Скорее проблема в том, что вы не подготавливаете данные для запроса - экранировать их нужно. Коли используется mysqli, то используйте подготовленные запросы, либо производите сами экранирование перед записью.
Почему самоубийство если связаны - потому, что если рассматривать этот набор как ключи чего-то найденного, то их нельзя будет связать с найденным. Простой пример, есть заявки - ключ => значение. Необходимо удалить заявки значение которых равно N. Попробуйте решить эту задачу средствами sql, если ключи заявок, это строка и не важно в каком формате. |
Часовой пояс GMT +3, время: 16:39. |