Связать два select

[warren buffet]

В ней сразу сформирован номер(ид корзины) будущей

Ну вот она ахинея. Сущность напялена на другую сущность и получается типа формула, в которой одна из переменных - результат вычисления этой же формулы. Ты теорему несуществования доказать решил? Ты доказал.

select * from tablename where brand='Конь тыгыдымский'

Получил листинг. Там еще могут быть опции сокращения выборки. Понажимал, получил. Теперь хочешь запомнить какую-то запись из списка. Где ее запомнить? Где угодно, главное, чтобы была привязка к юзеру. Автоматическую привязку обеспечивают куки, поскольку они доступны и на сервере. Без куков можно обойтись только принудив юзера регистрироваться, поскольку тебе нужен его ID, привязка к его сущности.

Юзер тычет "сохранить" скрипт запоминает в куках или в бд. Юзер тычет "оформить" или там "корзина", скрипт достает список запомненного и выводит.

select * from tablename where product_id in(join(',',$saved_id_list));

Все нах.

[warren buffet]

Данные из БД - рид-онли. А все юзерские списки - едитабле. Виш-лист, избранное, лайки, корзина - это юзерские списки. Виш-лист это просто идешники, лайки это пара идешник - оценка, корзина это пара идешник - количество. Что ты еще можешь изобрести сверх этих архаичных сущностей? Капец блин, захерачат сами себе могучий Маня-мир и мудохаются в нем с уродской аксиоматикой. Ты и попал сюда из Маня-мира. Если бы ты изучал реальный мир, тебя бы сдесь не было. Давно бы уже написал все, ну максиумм бы пришел пожаловаться почему == сравнивает блеать без типа.

[laimas]

Ты, видимо, родился со знанием как правильно сайты делать

Нет, я как и все родился без штанишек.

Не берите на веру, что фореймворки есть де-юре Закон, а следовательно в них все безупречно. Сперва рассмотрим вот это:

var id_regex = new RegExp('(' + prefix + '-\\d+-)');
var replacement = prefix + '-' + ndx + '-';

Уже плохо, так как используется разбор рег. выражением, что уже накладно. А ведь если и требуется нумерация, можно ведь поступать так же как в жизни - ул. Академическая 1, ул. Академическая 2, ... Знакомо? Да и от программирования весьма далеко, но ведь просто.
Если это взять на вооружение, то в первичный список в атрибут data-num помещать номер, а связанный с ним список получает ID как например s1, s2, s3, ... Для обращения к связанному списку получаем номер из атрибута и соединяем его с "s" и получаем ID элемента к которому нужно обратиться.

Но что самое ужасное, так это именование полей так же дремуче как и ID элементов. Что придется делать на сервере - сервер получает вот такой набор ключей form-1-buy_tabako_brand, form-2-buy_tabako_brand, form-3-buy_tabako_brand и т.д. Для простоты опустим факт того, что серверный сценарий должен проверять наличие ожидаемых им ключей, и пусть "берем на веру, что все гут", а данные присланные для одного адресата. Тут можно не интересоваться именами ключей, а получить их значения и далее по условию.

Но если даже веровать, то ситуация резко усугубится, если данные будут присланы для двух адресатов, и второй набор будет таким form-1-buy_bibika_brand, form-2-buy_bibika_brand, form-3-buy_bibika_brand и т.д. Просто взять значения каждого из наборов и далее оперировать ими уже не получится. Серверный сценарий вынужден будет производить разбор каждого ключа, что просто сводит на нет все удобства работы с массивом. Ладно если ключей раз, два и все, а если представить, что таким же образом именовать поля формы где либо в административном разделе, с большим числом записей предполагающих пакетное обновление? Это будет кошмар.