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

[Тугай]

arhat78, нельзя не бывает один ботинок и трех размеров. Ботинок 15 и ботинок 30 размера не могут одинаково стоить.
Да и детям дешевле надо продавать.

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

В корзину летит не размер, а товар (SKU). Товаром является ботинок нужного размера и с соответствующей ценой.

 

[arhat78]

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

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, и так далее. кто то подсказал, что так лучше привязывать размер и выводить его. вот так пока и действую...

 

[arhat78]

Тугай, то есть, мне легче в таблицу products занести колонку size. Это получается, что если есть ботинок с пятью размерами, то нужно в таблицу занести пять экземпляров с разными размерами (получается у каждого ботинка с произвольным размером будет свой id), и выводить.... Хорошо, а как тогда можно будет выводить размер выпадающим списком, и как выбранный размер будет идентифицироваться именно с этим выбранным ботинком?

 

[artoodetoo]

Дался вам "выпадающий список"! Получить из любой таблицы список уникальных значений можно с помощью DISTINCT либо GROUP BY.

 

[arhat78]

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

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


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

и здесь выбранный размер не имеет своего уникального "id". Тупик какой то, пока....

 

[arhat78]

Дался вам "выпадающий список"! Получить из любой таблицы список уникальных значений можно с помощью DISTINCT либо GROUP BY.

artoodetoo, не серчайте так - я же только учусь Пока пытаюсь понять, как сделать код оптимальным........

 

[artoodetoo]

Я и не думал серчать ))) Сделайте чтобы работало, а "оптимально" может быть и не понадобится.

 

[arhat78]

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

 

[rdbn]

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

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

собственно - это все что требовалось.

 

[arhat78]

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

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

собственно - это все что требовалось.

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

 

[rdbn]

просто сравнить через "==" то значение что вы передаете с тем что уже есть в массиве.

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

 

[arhat78]

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

Раньше не занимался. Осенью начал читать литературу, но 3 месяца изучения мало чего понял. Потом начал пробовать на практике, тогда дело уже веселее пошло. Сейчас хоть уже начинаю понимать статьи из учебников, когда вижу, как это на практике применяется.

 

[Redjik]

arhat78, нельзя не бывает один ботинок и трех размеров. Ботинок 15 и ботинок 30 размера не могут одинаково стоить.
Да и детям дешевле надо продавать.

Муахаха ... ты когда последний раз в магазине был?
Ботинки разного размера могут и более того стОят одинаково.
С поправкой одной, детская обувь стоит ДОРОЖЕ.

 

[AnrDaemon]

rdbn, в таких случаях делается VIEW на обе таблицы и используется для работы с товаром при продаже.

 

[arhat78]

rdbn, в таких случаях делается VIEW на обе таблицы и используется для работы с товаром при продаже.

Пытаюсь найти инфу о VIEW, но что то совсем печально - ничего понятного не нашёл. В общем, совсем запутался

 

[флоппик]

Муахаха ... ты когда последний раз в магазине был?
Ботинки разного размера могут и более того стОят одинаково.

Зато ботинки привезенные в разных партиях - вполне могут стоить по разному. А еще по разному будут стоить одинаковые ботинки, проданные по разной цене в разное время. Поэтому-то цена не является прямым свойством товара, а зависит от суммы косвенных признаков.

 

[Redjik]

http://dev.mysql.com/doc/refman/5.6/en/views.html

rdbn, в таких случаях делается VIEW на обе таблицы и используется для работы с товаром при продаже.

я бы не стал так делать, для меня view это
1) Или лень
2) Или запрос настолько зубодробилен, что легче view накидать

 

[Lionishy]

Я пролистал тему, попробую сформулировать проблему с моей "колокольни". В модели есть несколько ейдосов: Size ; ISizeAware ; ISizeChoosable ; Shoe ; ViewShoe: public Shoe, ISizeChoosable ; OrderShoe: public Shoe, ISizeAware ;

Не важно как там оно в persistance layer.
Все пляски вокруг того, что ViewShoe и OrderShoe кажутся одним и тем же (Shoe), но вообще не одно и тоже (ISizeChoosable <> ISizeAware).
Так вот всё, что нужно для решения сложившийся ситуации -- это осознать, что ViewShoe <> OrderShoe, и описать эти две разные сущности.
И потом уже всё встанет на свои места и в persistance.

 

[AnrDaemon]

http://dev.mysql.com/doc/refman/5.6/en/views.html

я бы не стал так делать, для меня view это
1) Или лень
2) Или запрос настолько зубодробилен, что легче view накидать

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

 

[arhat78]

Хорошо, с проверкой if-else пока не получается - можете скинуть ссылку на этот VIEW, что то полезной инфы не нашёл пока...