Есть таблица со значениями: id, title, description. И есть набор значений, который необходимо хранить в таблице, что можно сделать двумя способами: В виде сериализованной строки: '{"a":1,"b":2,"c":3}' в поле description, которую затем разбирать PHP: $arr = json_decode($json, true); $a = $arr[0]; $b = $arr[1]; $c = $arr[2]; Добавить в таблицу три столбца, в каждом из которых хранить в виде строки значения, соответственно, для $a, $b, $c, и которые в дальнейшем можно запрашивать и использовать без необходимости декодирования и получения в виде значения массива. По ряду причин для меня более приемлемым является первый вариант. Одна из причин - нет ограничений на количество вариантов значений: хоть три, хоть десять элементов можно хранить в виде сериализованной строки, а затем получать в качестве элемента массива, чего я буду лишён, если количество значений будет задано имеющимися столбцами таблицы. Но этот же вариант менее производителен, поскольку приведение сериализованной строки к массиву и взятие элемента - это стоимость такого способа хранения данных. Прошу совета, насколько расточителен (или нет?) первый вариант хранения данных с двойным преобразованием перед использованием? Есть какие-то общепринятые подходы в подобных случаях?
@118_64, можете ответить всего на один вопрос? Для чего нужна База Данных, не в вашем конкретном случае, а если мыслить глобально?
Могу дать ответ из Википедии. Лично мне нужна для хранения данных эффективным способом, под которым я понимаю некое сочетание производительности и вариативности хранимых данных.
База данных нужна для ОБРАБОТКИ информации, хранение данных в БД - это всего лишь приятный бонус. А вот того что бы обрабатывать эти самые данные их надо хранить в подобающем виде. Почитайте про нормализацию баз данных. К примеру ваш первый вариант это прямое нарушение первого закона нормализации. Если есть непреодолимое желание хранить данные в таком виде, то лучше использовать NoSQL базы данных. Ваш второй вариант (правильный вариант) - это классика жанра. Ну и в конце концов БД умеет хранить данные в JSON формате, но обработка в таком виде хуже чем при классическом варианте.
@118_64 таблица description : Код (Text): id | name 3131 | a 3462 | b 4436 | c 3456 | d 7451 | e 3109 | f таблица2: Код (Text): id | title | description_id | sum 231231 | название | 3131 | 1 321332 | название | 3462 | 2 565563 | название | 4436 | 3 --- Добавлено --- да нормально тут все PHP: select des.name, sum from table2 as t left join description as des on des.id = t.description_id $result = [{'name' => 'a', 'sum' = '1'}, {'name' => 'b' ,'sum' => '2'}, {'name' => 'c' , 'sum' => '3'}];
@118_64 если потом из результата запроса хотите сделать массив как у вас, то так можно: PHP: $result = [ ['name' => 'a', 'sum' => '1'], ['name' => 'b' ,'sum' => '2'],['name' => 'c' , 'sum' => '3'] ]; $arr = []; foreach($result as $item){ $arr[$item['name']] = $item['sum']; } print_r($arr);
еще мона, но не комельфо PHP: $result = ... print_r ( array_combine ( array_column ( $result, 'name' ), array_column ( $result, 'sum' ) ) );
Ну, пробуем перечитать. JSON в базе - это не что-то новое или нестандартное, в том же pgsql jsonb (не json) существует с 2014 года, активно развивается и многими используется. По нему делаются выборки, строятся индексы, при чем при желании очень хитрые индексы позволяющие дешево делать выборки напрямую под ключам / массивам в значении поля. Предлагать ради одного поля переходить на nosql-решения или избавляться от такого формата данных их нормализуя - в корне не верно, по крайней мере не выяснив сколько будет этих данных, как с ними планируется работать и что используется как хранилище. И да, уходить от нормальной формы - это может не самая лучшая, но и не самая редкая практика. Чем?
@romach, тем, что по умолчанию если не оговорено иное БД это MySQL. Вы можете сколь угодно долго цепляется к моим словам, а можете объяснить ТС данный материал как считаете нужным. Маленькому ребёнку гораздо проще показать на коробок спичек и сказать нельзя, чем долго и нудно приводить примеры из жизни подкрепляя свои слова статистикой пожаров. Придёт время и он поймёт, что к чему. Примерно такая же ситуация с начинающими программистами.
В mysql всё это тоже есть, применяется и используется. С несколько другим подходом, с которым я на практике особо не знаком (и потому сослался на pgsql), но всё же. Ну так я и привел альтернативное мнение. Объяснять подробно смысла не вижу, всё это подробно описано в документации и куче статей. ТС захочет - прочитает, теперь у него хотя бы есть выбор.
@romach, я знаю что есть, поэтому и написал об этом третьим пунктом. А то что реляционной бд (включая и pgsql) сложнее работать с противоестественным для нее форматом, коим является json, то я тут при чём? Первый вариант ТС это хранение неатомарных данных в поле с типом varchar. Поэтому я и посоветовал nosql решения.
Только вот контексты разные. Там json-поле не к месту, тут - к месту, потому что если взять из тех ответов все верные аргументы (ну, "у json нет индекса потому медленно-медленно" - это не серьезно), то окажется что они применимы там и весьма спорны тут. Впрочем, дискутировать на такие темы - скучно, разве что синтетику запилить по быстрому для наглядного сравнения.
Да можно например наглядно сравнить как сделать поиск с like по атрибуту json и нормализованному столбцу в mysql.