Меню
Что нового?

Интернет магазин. Хранение корзины товаров.

  • Автор темы Автор темы arhat78
  • Дата начала Дата начала
Статус
В этой теме нельзя размещать новые ответы.
arhat78, нельзя не бывает один ботинок и трех размеров. Ботинок 15 и ботинок 30 размера не могут одинаково стоить.
Да и детям дешевле надо продавать. :)

Если в таблицу sizes добавить поле с ценой price и переименовать ее в products, то все встает на свои места.

В корзину летит не размер, а товар (SKU). Товаром является ботинок нужного размера и с соответствующей ценой.
 
Последнее редактирование:
rdbn написал(а):
если честно я не особо понимаю, а как вы определяете у какого товара есть какие размеры ? или я так понимаю у вас не может быть такой ситуации, что именно у этого товара не будет данного размера.

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

rdbn, в таблице размеров есть колонка id_boot, и колонка size. и получается id_boot - 1 = size - 19, id_boot - 1 = size - 20, id_boot - 1 = size - 21, id_boot - 2 = size - 19, id_boot - 2 = size - 20, id_boot - 2 = size - 21, и так далее. кто то подсказал, что так лучше привязывать размер и выводить его. вот так пока и действую...
 
Тугай, то есть, мне легче в таблицу products занести колонку size. Это получается, что если есть ботинок с пятью размерами, то нужно в таблицу занести пять экземпляров с разными размерами (получается у каждого ботинка с произвольным размером будет свой id), и выводить.... Хорошо, а как тогда можно будет выводить размер выпадающим списком, и как выбранный размер будет идентифицироваться именно с этим выбранным ботинком?
 
Последнее редактирование:
Дался вам "выпадающий список"! Получить из любой таблицы список уникальных значений можно с помощью DISTINCT либо GROUP BY.
 
Тугай, пробую проверку выбора размер сделать, но пока не получается.... Какая структура проверки должна быть? Получается, с помощью какой то функции нужно проверить, есть ли уже такой размер, и если есть, то записать новый. Но размер выбираю с помощью этого:
PHP: 
  $size = $_GET['size'];
  $_SESSION['cart_size'][$id] = $size;


  $b['size'] = $_SESSION['cart_size'][$id];

и здесь выбранный размер не имеет своего уникального "id". Тупик какой то, пока....
 
artoodetoo написал(а):
Дался вам "выпадающий список"! Получить из любой таблицы список уникальных значений можно с помощью DISTINCT либо GROUP BY.
Нажмите для раскрытия...

artoodetoo, не серчайте так - я же только учусь :) Пока пытаюсь понять, как сделать код оптимальным........
 
Я и не думал серчать ))) Сделайте чтобы работало, а "оптимально" может быть и не понадобится.
 
artoodetoo, допустим вывел я размеры с помощью group by из таблицы products. Покупатель выбрал размер 20, жмёт "добавить в корзину", затем выбирает 22й размер и жмёт "добавить в корзину". Как карточка продукта и корзина узнают и примут выбранные размеры?
 
PHP нечего не узнает если вы сами не скажите, что ему с этими данными делать, как я уже писал ранее сделайте проверку, которая должна проверять, есть ли такой товар в корзине и есть ли у него такой размер, что делать если один из пунктов не удовлетворен я уже писал, по существу надо просто написать две конструкции:

if (проверяем есть ли товара с таким id в сессии)
{ если товар есть
if (проверяем есть ли у него размер)
{ то все ок оставляем сессию без изменений }
else
{ если размера нет то добавляем ему размер }
}
else
{ добавляем id товара в сессию если такого id нет }

собственно - это все что требовалось.
 
rdbn написал(а):
PHP нечего не узнает если вы сами не скажите, что ему с этими данными делать, как я уже писал ранее сделайте проверку, которая должна проверять, есть ли такой товар в корзине и есть ли у него такой размер, что делать если один из пунктов не удовлетворен я уже писал, по существу надо просто написать две конструкции:

if (проверяем есть ли товара с таким id в сессии)
{ если товар есть
if (проверяем есть ли у него размер)
{ то все ок оставляем сессию без изменений }
else
{ если размера нет то добавляем ему размер }
}
else
{ добавляем id товара в сессию если такого id нет }

собственно - это все что требовалось.
Нажмите для раскрытия...

Вот в теории я это так себе и представляю, а вот на практике - id товара я проверю, а как проверить размер? Вот уже лежит в корзине 19й размер; и как с помощью проверки размера узнать, что именно 19й уже лежит, и можно положить следующий (22й, например)?
 
просто сравнить через "==" то значение что вы передаете с тем что уже есть в массиве.

да вот еще вопрос, а вы совсем не когда до этого не занимались программирование ?
Просто если честно, то вам не этим в этом случае надо заниматься, а для начала почитать основы, как php так и mysql
 
rdbn написал(а):
да вот еще вопрос, а вы совсем не когда до этого не занимались программирование ?
Просто если честно, то вам не этим в этом случае надо заниматься, а для начала почитать основы, как php так и mysql
Нажмите для раскрытия...

Раньше не занимался. Осенью начал читать литературу, но 3 месяца изучения мало чего понял. Потом начал пробовать на практике, тогда дело уже веселее пошло. Сейчас хоть уже начинаю понимать статьи из учебников, когда вижу, как это на практике применяется.
 
Тугай написал(а):
arhat78, нельзя не бывает один ботинок и трех размеров. Ботинок 15 и ботинок 30 размера не могут одинаково стоить.
Да и детям дешевле надо продавать. :)
Нажмите для раскрытия...
Муахаха ... ты когда последний раз в магазине был?
Ботинки разного размера могут и более того стОят одинаково.
С поправкой одной, детская обувь стоит ДОРОЖЕ.
 
rdbn, в таких случаях делается VIEW на обе таблицы и используется для работы с товаром при продаже.
 
Redjik написал(а):
Муахаха ... ты когда последний раз в магазине был?
Ботинки разного размера могут и более того стОят одинаково.
Нажмите для раскрытия...
Зато ботинки привезенные в разных партиях - вполне могут стоить по разному. А еще по разному будут стоить одинаковые ботинки, проданные по разной цене в разное время. Поэтому-то цена не является прямым свойством товара, а зависит от суммы косвенных признаков.
 
Я пролистал тему, попробую сформулировать проблему с моей "колокольни". В модели есть несколько ейдосов: Size ; ISizeAware ; ISizeChoosable ; Shoe ; ViewShoe: public Shoe, ISizeChoosable ; OrderShoe: public Shoe, ISizeAware ;

Не важно как там оно в persistance layer.
Все пляски вокруг того, что ViewShoe и OrderShoe кажутся одним и тем же (Shoe), но вообще не одно и тоже (ISizeChoosable <> ISizeAware).
Так вот всё, что нужно для решения сложившийся ситуации -- это осознать, что ViewShoe <> OrderShoe, и описать эти две разные сущности.
И потом уже всё встанет на свои места и в persistance.
 
Redjik написал(а):
http://dev.mysql.com/doc/refman/5.6/en/views.html

я бы не стал так делать, для меня view это
1) Или лень
2) Или запрос настолько зубодробилен, что легче view накидать
Нажмите для раскрытия...
Если запрос со многими объединениями (как здесь) - естественно, легче VIEW "накидать", как вы изволили выразиться. Особенно, если обращения к этому представлению идут постоянно и в больших количествах.
Не потому, что это настолько легче (= лень), а потому, что это сильно облегчает написание кода для работы с этим объединением (= оптимизация).
Плюс, если в последствии структура БД меняется, мне не нужно переписывать все запросы, где упоминается одна из участвующих в представлении таблиц - достаточно подправить само представление.
Тут самое главное - не включать в представление лишней информации.
 
Хорошо, с проверкой if-else пока не получается - можете скинуть ссылку на этот VIEW, что то полезной инфы не нашёл пока...
 
Статус
В этой теме нельзя размещать новые ответы.
Сверху