Вывод товара в корзине

[laimas]

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

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

Он простого то связать не может, а ты тут слюни распускаешь о MVC. Ну клоун блин, и откуда вы только такие беретесь. )

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

[kostyanet]

Из того же запроса еще можно узнать какие есть модели 38-го размера.

http://sqlfiddle.com/#!9/2a49f/4 - я вписал Value, но правильно вписывать id размера.

Магия SQL в том и состоит, что можно осматривать одни и те же данные с разных точек зрения и каждая дает свой полезный результат.

[kostyanet]

ты, умник хренов, всего лишь переименовал ее в model. И что же ты тут такого нового сказал?

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

Потому что SQL это блеать не массивы и не матрицы, именно в SQL реализовано нормальное человеческое понимание информации, ну, в какой-то мере, насколько SQL может обеспечить.

Поэтому если человек понимает неправильно - просто назвал не так, значит он думает не так и будет делать не так и получит хера, а не результат.

Очень важно при проектировании реляционных бд ЧЕТКО понимать как будут устроены все отношения. Чтобы начать это четко понимать, надо делать простые схемы, забивать данными, делать запросы и смотреть что получается. Переделывать, смотреть, переделывать, смотреть и так пока не начнешь ЧЕТКО понимать все отношения. Только тогда база будет жить.

Что касаемо французского

Курите joint свернув из своих доктрин.

[laimas]

arhat78,

Не слушайте бредятину что несет этот "умник".

Вам надо учится, а учатся, как это не странного, с малого, счетные палочки, цветные кубики. Сделайте отдельно две простых таблицы, в одной товары как и есть у вас, не важно что, просто слова "Имя 1", "Имя 2"...

А во второй просто это id товара и размеры. Каждая запись ее это наличие размера у товара, то есть и id товара, и размеры могут повторяться в полях (колонках таблицы). Но пара значений каждой записи (строки таблицы), это уникальное значение - укажите паре этих полей уникальный индекс.

Теперь простыми запросами, без всяких Ajax и прочих наворотах, отправкой обычной формы, в которой можно выбрать товар и его размеры, и пусть пока только по одной паре. Принимая форму добавляйте/изменяйте товары в корзине.

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

[kostyanet]

laimas, вы же описали то, что ТС сам придумал. У него так и сделано, в точности. И нихера не работает. Потому что и не должно.

Короче, вы сами напросились.

Назовите принципиальное отличие схемы prods из того самого http://sqlfiddle.com/#!9/2a49f/4 от схем sizes и model.

Если осилите и ответите - и сами все поймете и автору темы расскажете. Не осилите - я сам завтра объясню.

[laimas]

Поумничать охота или языком почесать как всегда? Мне не надо уроков по данному курсу, а ему даже и не пытайся этого втолковать, рано ему еще это переваривать, не поймет этих вещей он, не поймет главного - выгоды. Или ты этого до сих пор не понял?

Чешешь блин то одно, то другое, да еще с "пальчиками растопыренными". А коли времени дохрена лишнего, ну так втолковуй вначале простые вещи, с ними как и у любого начинающего у него проблемы. И ты тут еще со своим поносом о высоких материях, ну зачем это?

Лично я учусь по материалам "в твердых переплетах", и не вправляй мне тюльки.

[kostyanet]

Слив защитан, laimas не знает об отношении n:M.

Отношения между схемами могут быть

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

1:n - каноничное отношение, подавляющее число отношений 1 ко многим (number - числу). По заранее известному ключу строится результирующая таблица (result, recordset) с необходимыми данными. Например запросить из таблицы "фотки" - все имена файлов фоток товара по id товара.

n:M - многие ко многим (number to many) еще можно number to number, или many to many. - в сущности это двойное отношение 1:n между двумя сущностями в отдельных таблицах.

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

Отношение многое-ко-многому и отражает сущность такой клонированной сущность как пара обуви.

До чего господа и не могли допереть 6 страниц. Хорошо что есть kostyanet, пришел и всех спас.

[kostyanet]

"Размер" обуви насколько я помню без проверки - это просто номер колодки. Была попытка привести его к метрическим, к реальным, например 43-й это 27.5 см - не знаю почему, вроде бы провалилась.

Так вот если потребовать от оператора точно вводить собственно размер, то не нужна будет таблица размеров где все номера забиты раз и навсегда. Размеры окажутся в таблице каталога и запросы станут проще на 1 join и станут обычным 1:n отношением, где таблица моделей просто снабжает каталог наименованиями.

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

ЗЫ На снимке с админки где показано устройство списков, страна относится к товару, а не к коллекции, потому что товар может не быть в коллекции. Приходится на все товары втыкать страну, а иначе бы пришлось делать коллекции для одного-единственного товара чтобы у него страна появилась. Там товары в коллекции могут отличаться размером, цветом и даже дизайном, но коллекции как таковые вообще не выводятся, они только обеспечивают связь между товарами по cid. Скрипт получает товар, смотрит его cid, если он не null, скрипт запрашивает все товары с таким же cid кроме того который он получил - что нашлось, то выводится как "другие товары коллекции".

[laimas]

До чего господа и не могли допереть 6 страниц. Хорошо что есть kostyanet, пришел и всех спас.

Вот это другое дело, когда без пальцев растопыренных. ) Беда не в том, что слов он русских не понимает, а в том, что сути этого написанного, а также ранее, и гораздо проще, он не понимает, это ты понимаешь или нет?

Не надо тут блистать познаниями, и устраивать дебаты между нами, это спам в топике будет, который ему пользы не принесет. Вот когда он поймет, что эта структура базы данных и самое главное почему эта означает 99% успеха в проекте, вот это можно сказать, что это познания "не под копирку слов чужих".

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

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

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

[kostyanet]

Специально для облегчения судеб таких как вы и придуман сайт govnokod.ru отпостите туда смишное от заказчика.

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

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

А вы думали внедрежом 1с люди занимаются за хорошие деньги просто так? И кстати лучшие внедреженцы из тех самых товароведов, которые освоили проектирование и программирование.