Что у вас за сервер - смесь английского с французским? Замените USING(pid) на ON, указав поля соответствующие и алиасы. Ругается на неоднозначное определение id, чего-то у вас попутано.

А вообще, разберитесь с сервером своим, выбросьте в помойку WAMP и установите Open Server, с удобной конфигурацией, с приличными возможностями. Ну что за фигня, что еще и во французском разбираться?

Долбоящер, там написано "left joint" - джоинтом называют козью ногу, косяк. А в SQL - join. Собственно на французском то и написали.

Ну все верно, в такой черезжопной системе таблица размеров превращается в каталог товаров, а каталог товаров превращается в подчиненный список таблицы размеров.

Затем еще кусок гавнямбы: чтобы завести товар надо сделать минимум 2 записи - в списке товаров и каталоге размеров, иначе товар из списка попросту никогда не появится в результатах запросов.

Точно так же, как не появляется размер, которого попросту нет в нормальном каталоге товаров, но у ТС-а же все через жопу, а этот долбоящер laimas с удовольствием наблюдает как информационное животное мучается.

Знаете laimas зачем ТС придумал такую задницу? Затем что у него нет таблицы моделей. Без которой нельзя выбрать все ботинки одной модели чтобы посмотреть какие там есть размеры. Таблица sizes тем и занимается - группирует по size_id те самые модели. Но там нет их названия и чтоб завести новый ботинок той же модели, надо сделать 2 записи, а не 1 - в двух таблицах всегда.

А вы кажется хорошо знаете постулаты реляционных БД? Как звучит предикат - факт хранится в одном месте?

У ТС факт хранится в двух местах и поэтому оно никогда не будет работать нормально. Я уж не говорю о том, когда ТС захочет еще какую-то проперть завести кроме размеров - вот будет умора почитать.

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

table model
id
name

заводим 1 - Ботинки Андрей, 2 - Туфли Игорь, 3 - Кроссовки Эдик.

table listing
id
model_id
size_id

заводим запись, выбираем в поле model из списка - Ботинки Андрей, а в поле size из списка - 44 - ОК
заводим запись, выбираем в поле model из списка - Ботинки Андрей, а в поле size из списка - 42 - ОК
заводим запись, выбираем в поле model из списка - Ботинки Андрей, а в поле size из списка - 41 - ОК
заводим запись, выбираем в поле model из списка - Ботинки Андрей, а в поле size из списка - 40 - ОК
заводим запись, выбираем в поле model из списка - Ботинки Андрей, а в поле size из списка - 38 - ОК

сделали 5 размеров Андрея

Теперь остается соединить три таблицы и получить полный фарш.

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

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

Что и требовалось рассказать. Вы 0 без знака в проектировании баз данных, синтаксиса не видите, по-французски не читаете, но беретесь учить того, чей уровень минус стопицот. Видимо по той самой причине, что минус стопицот, иначе оттянуться не получится.

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

Тогда запрос

select p.id, p.name, s.size
from sizes as s
left join products as p
on s.prod_id = p.id

обогатит таблицу размеров - наименованиями. А если его закончить вот так

where s.prod_id = 33;

то получим наименование для всех размеров.

Можно поменять таблицы местами, можно поменять left на right - нихера не поменяется. Так и будет через жопу, потому что список товаров находится в таблице размеров и именно в нее добавляются наименования по id товара из таблицы наименований.

Я вам блеать с первого раза кажется обоим пытался объяснить что все сделано через жопу, наоборот. Но вы ж долдоните каждый свое распространяя невежество в и так пропащем рунете.

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

Посмотрел в рунете обувные - все гавно. Лямода которая рекламируется в ящике, догадалась выдавать модельные цвета в блоке Мы рекомендуем. У остальных долбоящеров с топа гугля все еще хуже.

Прикол еще на лямоде, у них типа складская программа заведена в интерфейс. Каждый щелчок по + в корзине вызывает шквал эмоций в заголовках к серверу и обратно. Ну, типа, проверяют "на складе" - сколько осталось. Я нащелкал по-быстрому больше полсотни, небось теперь больше никому не достанется. :)

kostyanet, здесь список размеров выпадает из БД в Арт.10001, Арт.10002 http://top-top.bl.ee/index.php?view=product&id=2
Это пока всё, что успел "наваять"....

В вашими подсказками по коду дома пока не могу пробовать - завтра на рабочем нетбуке будут тренироваться.

Оказывается на sql тоже есть fiddle

http://sqlfiddle.com/#!9/2a49f/1

запрашивать модель по id - не эстетично, поэтому добавлено поле path, которое и будет светиться в адресной строке браузера, в ссылках.

Меняете path на соответствующий, как если бы он менялся в браузере и видите какие размеры имеются у той или иной модели.

Все просто? Все просто до невозможности если сделано нормально.

Логика приложения такова select * from model; и генерим с результата список ссылок с адресами в конце которых тот самый path.

Юзер нажимает на ссылку. Сервер получает запрос, контроллер видит что фрагмент адреса, там где может быть path - имеется. Значит загружается модель продукта - не модель ботинка, тут просто совпадение слов, - модель из сокращения MVC, то есть скрипт который готовит данные для рендера продуктовой страницы. Этот скрипт должен показать наименование и список размеров. Наименование есть в модели, значит можно тупо сделать 2 запроса,

1: select * from model where path = $escaped_quoted_path;

что дает всю инфу по модели, в том числе ее id. И тогда второй -

2. select prods.id, size.value from prods left join size on prods.size_id = size.id where prods.model_id = $res['id']

- загрузит список имеющихся размеров выбранной модели. Улавливаете? Список загружается в "формате" id продукта - размер.

Когда юзер выбрал размер и нажал кнопку Купить, в корзину валится пара id продукта и количество. То есть все как обычно, ибо по-другому и быть не должно.

После оформления юзер отправляет на сервер эти самые данные - ид продукта и количество. Какие теперь проблемы узнать что он заказал и какого размера?

Никаких. Вот так мы узнаем по id все что нужно знать:

http://sqlfiddle.com/#!9/2a49f/2

В тот же самом запросе на полный фарш меняем where на where p.id=4

Жизненный цикл завершен.