Вот как делается

{"123":{"q":1,"p":37070},"126":{"q":1,"p":30600}," 186":{"q":4,"p":6920}}

это записывается в куку юзера. p это - price - чисто ритуальная фича, на случай если юзер заказал в пнд, а во вт ценник поменялся, а он начал оформлять, тогда ему скажут - чувак, с тех пор ценник поменялся, продолжать по новой цене или как?

q - quantity - количество. А без названия - тот самый id, который и в json - id.

В бд заказ записывается только после оформления. Можно записать нормально, но кому оно надо - пишется как есть, тот самый json, поскольку под него уже есть интерфейс просмотра-редактирования, который и с заднего входа заюзан для этого поля. То есть оператор видит заказ точно так же, как видел его заказчик. Это важно, потому что глюки разных интерфейсов могут вызвать неоднозначность в финансовых вопросах. Когда код один на всех - то и возможные глюки у всех одинаковые.

Блеа, это не екзель, тут не надо копипастить данные как в дебильном екзеле.

Как же вы приложения пишите, если вообще не имеете представления о том, что же возвращает серверу форма?

Если опции этих списков, и пусть условно с именами maker1 и maker2, списка содержат ID товаров, и например будут выбрано у первого опция со значением 123, а у второго 200, то $_POST[] будет содержать:

Array (
[mker1] => 123,
[mker2] => 200
)

какие к черту $value['Price'] и иное, если они не являются значением свойства value опций списка? И еще раз повторить, что они серверу и нафик не нужны? Север получил главное - ID товаров, и если уж хранить этот выбор, то хранят ID и выбранное количество, все остальное зачем? Ведь получить цену и имя фото товара можно всегда запросом к таблице его описывающей:

$sql = 'SELECT price, photo FROM table_name WHERE id=' . (int)$_POST['maker1'];

Здесь $_POST['maker1'] - это для примера, ибо как уже говорил, записывать price, photo у товаров выбранных списками в какую-то таблицу нет никакого смысла. Надо получить где-то это и вывести, значит запрос к таблице, в которую вы пытаетесь "INSERT ...", получить в ней ID и количество сохраненные этим "INSERT ..." при получении формы, и в этом запросе вложенный JOIN к таблице получить table_name за получением их price, photo.

kostyanet, я такое как-то сделаю, когда юзер самостоятельно будет собирать комплектующие: добавление в корзину и т.д
А это(с селектами) я делаю аля нажал на "оформить" и сразу получаешь расчетный лист (http://www.positive45.ru/print_form/list_r_k.php). Так нужно.

Короче, харе тупить. Как пишутся телеги известно давным давно. Реализации могут быть разные, зеленые и красные, а принцип одинаков - в телеге сохраняется только выбор юзера, то есть данные которые он сам генерит своими действиями. Выбрал товар - это id товара, id может быть любым, обычно это - число. Задал количество - это количество. Получаем пару - ид-количество, для экономии места в куке сокращаем до и-к, кодируем вручную в свой колхозный протокол, или индустриально - на языке json (см выше).

Вариант с бд - который как правило доступен после регистрации, то есть открытия счета юзером на сайте - отличается только тем, что пишем не в куки, а в бд

insert into cart (user_id,prod_id,quantity) values($user_id,$post['id'],$post['q'])

И все. Теперь чтобы открыть телегу юзера запрашиваем

select * from cart where user_id = $user_id;

Но получим просто список идэх, толку мало, поэтому просто пихаем телегу как фильтр к обычному каталожному запросу, например

select prods.* from prods
left join cart
on cart.prod_id = prods.id
where cart.user_id = $user_id;

и все, у нас полный фарш с каталожной таблицы, но выбраны только те товары, которые есть в тележке зарегиного и аутентичного юзера.

Я года два назад покупал у китаезов кое-какие вещи и с тех пор время от времени получаю мессаги типа "снижена цена на товары в вашем списке желаний". Это значит wish list сохранен с той ценой, которая была актуальна в момент добавления товара. То есть ценник можно сохранять как snapshoot, для применения в различных ситуевинах. Но не как цену товара по которой он сейчас продается. Актуальная цена всегда берется из выставленного счета, а счет выставляется или человеком в офисе, или на сайте из данных в таблице.

kostyanet, cпасибо за разъяснение! Надо посмотреть на БД магазинов. Особенно с категориями (видеокарты, процессоры). Ведь у каждого товара в категории свои свойства: графическая частота у видеокарты, а у процессора нету вообще(как пример).
Потому что у меня такие таблицы: http://prntscr.com/79jgxf это для кулеров.
Не правильно же созданны?
"Актуальная цена всегда берется из выставленного счета, а счет выставляется или человеком в офисе, или на сайте из данных в таблице"
Верно. У меня админ меняет цену. Только так.

Дальнейшее усложнение телеги вовлекает бухгалтерские сущности. В теории можно вести заказ по дате, но на практике делается еще одна таблица, в которую валятся сведения о самом заказе: оформили, отгрузили, сколько, чего, фактический адрес получателя, как платил, когда получил, когда отменил, когда закрыл и все такое. Это уже для магазов которые реально продают через сеть, выдают треки и в таком роде. Вашему все равно не светит.

Умора мля...

Я делаю для локального пользования. Минимально функций!