Цитата:
|
"Разошелся так и сыпеть, будь он параллелепипедь, будь он круг, ядрена вошь."
|
Вы laimas дрыгаетесь как Моська из-за моей лени читать ваши легенды. Но я могу и потрудиться. Например вот тезисы из тележищи сугубо по устройству реляционной базы данных воображаемого обувного магазина.
Цитата:
|
Потому что невежда. Все что вы пытались объяснить нубу, называется - метафора.
Например рабочий стол в Винде - это метафора рабочего стола человека, где лежат документы, банка с авторучками и карандашами, блокнот, счеты, ящики входящие-исходящие и все что обычно может лежать на рабочем столе. Папка в винде - это метафора папки в шкафу. В папке хранятся файлы - это метафора файлов - таких картонных карточек с записями например о персоналиях или товарах, или пациентах и тп. Товар на веб-странице интернет-магазина - метафора настоящего товара. Так вот реляционная БД не имеет метафоры. Это чисто компьютерная сущность, которая силой воображения и труда инженера может быть спроектирована как метафора реальной, привычной сущности, например полок обувного магазина. И вот когда у вас есть такой магазин, или вы хорошо, или вообще знаете как он работает, как обычно такие магазины работают, то не потребуется больших умственных затрат чтобы спроектировать БД под метафору такого магазина. А вот если не знаете - то ничего и не получится. Потому что нет прототипа. Не с чего метафорировать так сказать. Достаточно разок увидеть счет-фактуру того самого магазина чтобы понять как оно в общем и целом устроено. Возникает вопрос - откуда у ТС вообще идея тренироваться на продаже обуви, если он не бельмеса в этом деле? |
Цитата:
|
С таким кодом:
function get_product($id)
{
global $link;
$query = ("select products.*,sizes.size
from products
left joint sizes on sizes.id = products.size_id ");
$result = mysqli_query($link, $query);
if ($result)
{
$row = mysqli_fetch_array($result);
return $row;
}
}
выходит эта ошибка: Fatal error: Uncaught exception 'mysqli_sql_exception' with message 'Erreur de syntaxe prГЁs de 'joint sizes on sizes.id = products.size_id' Г la ligne 3' in C:\wamp\www\Shop\db_fns.php on line 143 И как выводить нужные размеры в списке через products.size_id? Ведь у каждого ботинка может быть определённые размеры, а в этой колонке можно поставить только одну цифру... |
Цитата:
Цитата:
|
Так у меня выводится карточка товара с описанием:
<table align="center" style="border-width: 1; border-style: dashed" class="product" width="200" height="200">
<tr>
<td valign="top" align="center" cellpadding="5" cellspacing="5">
<div><a href="#"><img src="userfiles/<?=$product['image']?>" width="150" height="100" alt="" /></a></div>
<div class="description">
<div class="product-name"><a href="#"><?=$product['title']?></a></div>
<div class="product-price">Цена: <?=$product['price']?> руб</div>
</div>
</td>
<td valign="top">
<div><?=$product['description']?></a></div>
<form action="index.php" method="get">
<fieldset> Размер:
<input type="hidden" name="view" value="add_to_cart">
<input type="hidden" name="id" value="<?=$product['id']?>">
<select name="size">
<?php
$result = $link->query("SELECT size FROM sizes WHERE `sizes`.`id_boot`='$id' ");
while ($b = mysqli_fetch_assoc($result))
{
echo "<option value='".$b['size']."'>" .$b['size']. " </option>";
}
?>
</select></fieldset>
<input type=image src="userfiles/8.jpg" width="60" height="60" value="Добавить в корзину">
</form>
</td>
</tr>
</table>
Такой кейс:
case ('product'):
$id = $_GET['id'];
$product = get_product($id);
break;
И функция выборки товара:
function get_product($id)
{
global $link;
$query = ("SELECT * FROM products WHERE id='$id' ");
$result = mysqli_query($link, $query);
if ($result)
{
$row = mysqli_fetch_array($result);
return $row;
}
}
Если в этой функции делаю тот код с left join, то и появляются та ошибка, которую привёл. А по поводу БД и таблиц. У меня есть таблица products с описанием товаров, и есть таблица sizes, где через size_id идёт ассоциация с id продукта. В ней получается: id size_id size 1 1 19 2 1 20 3 1 21 4 2 19 5 2 20 6 2 21 7 2 22, где size_id это id ботинка. И в карточке товара выпадающим списком выводится у ботинка id=1 размеры 19-20, у ботинка id=2 размеры 19-22. Я додумался только до такого вывода размеров...... |
У вас что "французский" SQL? :)
Ошибка потому, что объединение запроса не потому полю. ID размера это уникальный для размера ключ. Таблица продуктов не может содержать в себе ссылки на таблицу размеров, таким образом указывая как размеры есть у продукта. В противном случае придется дублировать каждую запись о продукте в этой таблице, а сделать этого нельзя, так как ID продукта тоже уникальное значение. Чтобы связать продукты с размерами, которые у них есть, нужна внешняя таблица связей между этими таблицами. Пусть таблица продуктов, условно products pid name etc 1 name 1 aaaaaa 2 name 2 bbbbbb Таблица размеров, условно proportions id size 1 19 2 20 3 21 4 22 А вот так они связываются через внешнюю таблицу, условно назовем ее relations: pid id 1 1 1 2 1 4 2 1 2 3 И у этой таблицы pid + id, это составной уникальный ключ, который не позволит одному и тому же продукту указать два и более раза один и тот же размер. Из этой таблицы видно, что продукт 1 имеет размеры 19, 20 и 22, а продукт 2 размеры 19 и 21. Если ведется учет количества размеров на складе, то эта таблица может содержать и поле описывающее это количество для каждого из размеров у каждого из продуктов. Чтобы получить товары и их размеры, запрос к таблице продуктов обращается к этой таблице соединяя их как ON relations.pid = products.pid А по полученному таким образом id размера из этой таблицы, объединяем в запрос и таблицу размеров как ON relations.id = proportions.pid Получаем такой запрос:
$q = mysql_query('SELECT *
FROM products
LEFT JOIN relations
USING(pid)
LEFT JOIN proportions
USING(id)
ORDER BY name, size');
Так как имена полей в таблицах по которым они связываются одни и те же что в родительских, что в таблице связей, то используется USING(). Результатом будет ресурс:
Array
(
[0] => Array
(
[id] => 1
[pid] => 1
[name] => name 1
[etc] => aaaaaa
[size] => 19
)
[1] => Array
(
[id] => 2
[pid] => 1
[name] => name 1
[etc] => aaaaaa
[size] => 20
)
[2] => Array
(
[id] => 4
[pid] => 1
[name] => name 1
[etc] => aaaaaa
[size] => 22
)
[3] => Array
(
[id] => 1
[pid] => 2
[name] => name 2
[etc] => bbbbbb
[size] => 19
)
[4] => Array
(
[id] => 3
[pid] => 2
[name] => name 2
[etc] => bbbbbb
[size] => 21
)
)
в котором проходом в цикле по ключу pid получаем описание товара и список его размеров. Вы в своем запросе пытаетесь связать таблицы как ID товара равно ID размера, что даже по логике несуразица, и об остальном можно и не говорить уже. |
Благодарю, переделал в БД таблицы, только вместо таблицы proportions оставил sizes. И списком размеры не выдаёт, пишет ошибки:
Fatal error: Uncaught exception 'mysqli_sql_exception' with message 'Champ: 'id' dans from clause est ambigu' in C:\wamp\www\Shop\views\pages\product.php on line 39 ( ! ) mysqli_sql_exception: Champ: 'id' dans from clause est ambigu in C:\wamp\www\Shop\views\pages\product.php on line 39 Line 39 это - ORDER BY title, size
<select name="size">
<?php
$result = $link->query('SELECT *
FROM products
LEFT JOIN relations
USING(pid)
LEFT JOIN sizes
USING(id)
ORDER BY title, size');
while ($b = mysqli_fetch_assoc($result))
{
echo "<option value='".$b['size']."'>" .$b['size']. " </option>";
}
?>
</select>
sizes вместо proportions title вместо name Да, по кодировке: пытаюсь выставить utf8_general_ci, но автоматически всё равно выставляется utf8mb4_general_ci..... Глюк какой-то...... |
Что у вас за сервер - смесь английского с французским? Замените USING(pid) на ON, указав поля соответствующие и алиасы. Ругается на неоднозначное определение id, чего-то у вас попутано.
А вообще, разберитесь с сервером своим, выбросьте в помойку WAMP и установите Open Server, с удобной конфигурацией, с приличными возможностями. Ну что за фигня, что еще и во французском разбираться? |
Цитата:
|
Цитата:
Затем еще кусок гавнямбы: чтобы завести товар надо сделать минимум 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 размеров Андрея Теперь остается соединить три таблицы и получить полный фарш. |
Цитата:
Цитата:
|
Цитата:
Без таблицы моделей будет невозможна группировка. Чтобы ее все-таки сделать, придется завести общий признак в любой другой таблице. ТС догадался это сделать в таблице размеров и получил все через жопу. Теперь не из каталога продуктов надо выбирать, а из таблицы размеров, ибо там - весь каталог оказался, а каталог продуктов стал простым списком - тех самых моделей. Тогда запрос 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 Жизненный цикл завершен. |
Цитата:
Он простого то связать не может, а ты тут слюни распускаешь о MVC. Ну клоун блин, и откуда вы только такие беретесь. ) Что касаемо французского, то ты кроме языка "четких пацанов" вроде бы нихрена и не знаешь, так что ля пардон. |
Из того же запроса еще можно узнать какие есть модели 38-го размера.
http://sqlfiddle.com/#!9/2a49f/4 - я вписал Value, но правильно вписывать id размера. Магия SQL в том и состоит, что можно осматривать одни и те же данные с разных точек зрения и каждая дает свой полезный результат. |
Цитата:
Вам долбоящеру надо было сразу это сказать и все давным-давно мы работало. Но вы же не знали что сказать и сейчас не знаете, поэтому только гадите. Потому что SQL это блеать не массивы и не матрицы, именно в SQL реализовано нормальное человеческое понимание информации, ну, в какой-то мере, насколько SQL может обеспечить. Поэтому если человек понимает неправильно - просто назвал не так, значит он думает не так и будет делать не так и получит хера, а не результат. Очень важно при проектировании реляционных бд ЧЕТКО понимать как будут устроены все отношения. Чтобы начать это четко понимать, надо делать простые схемы, забивать данными, делать запросы и смотреть что получается. Переделывать, смотреть, переделывать, смотреть и так пока не начнешь ЧЕТКО понимать все отношения. Только тогда база будет жить. Цитата:
|
arhat78,
Не слушайте бредятину что несет этот "умник". Вам надо учится, а учатся, как это не странного, с малого, счетные палочки, цветные кубики. Сделайте отдельно две простых таблицы, в одной товары как и есть у вас, не важно что, просто слова "Имя 1", "Имя 2"... А во второй просто это id товара и размеры. Каждая запись ее это наличие размера у товара, то есть и id товара, и размеры могут повторяться в полях (колонках таблицы). Но пара значений каждой записи (строки таблицы), это уникальное значение - укажите паре этих полей уникальный индекс. Теперь простыми запросами, без всяких Ajax и прочих наворотах, отправкой обычной формы, в которой можно выбрать товар и его размеры, и пусть пока только по одной паре. Принимая форму добавляйте/изменяйте товары в корзине. Все это на простых скриптах, отдельно от имеющегося. Вот как усвоите все, поймете что к чему, тогда эти познания уже можно перенести в скрипты магазина. Далее уже можно усложнять задачи. Вот так, а то и там немного не знаем, и это не понятно... ну так проще разобраться с какой либо проблемой узкой в отдельном и простом, нежели учитывать множество связей и условий в сложном. |
laimas, вы же описали то, что ТС сам придумал. У него так и сделано, в точности. И нихера не работает. Потому что и не должно.
Короче, вы сами напросились. Назовите принципиальное отличие схемы prods из того самого http://sqlfiddle.com/#!9/2a49f/4 от схем sizes и model. Если осилите и ответите - и сами все поймете и автору темы расскажете. Не осилите - я сам завтра объясню. |
Поумничать охота или языком почесать как всегда? Мне не надо уроков по данному курсу, а ему даже и не пытайся этого втолковать, рано ему еще это переваривать, не поймет этих вещей он, не поймет главного - выгоды. Или ты этого до сих пор не понял?
Чешешь блин то одно, то другое, да еще с "пальчиками растопыренными". А коли времени дохрена лишнего, ну так втолковуй вначале простые вещи, с ними как и у любого начинающего у него проблемы. И ты тут еще со своим поносом о высоких материях, ну зачем это? Лично я учусь по материалам "в твердых переплетах", и не вправляй мне тюльки. |
Слив защитан, 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, пришел и всех спас. :) |
"Размер" обуви насколько я помню без проверки - это просто номер колодки. Была попытка привести его к метрическим, к реальным, например 43-й это 27.5 см - не знаю почему, вроде бы провалилась.
Так вот если потребовать от оператора точно вводить собственно размер, то не нужна будет таблица размеров где все номера забиты раз и навсегда. Размеры окажутся в таблице каталога и запросы станут проще на 1 join и станут обычным 1:n отношением, где таблица моделей просто снабжает каталог наименованиями. К таблице моделей цепляется таблица категорий, сезонов, материалов и фич, затем брендов, а к таблице брендов цепляется таблица стран. К таблице товаров можно прицепить таблицу цвета. ЗЫ На снимке с админки где показано устройство списков, страна относится к товару, а не к коллекции, потому что товар может не быть в коллекции. Приходится на все товары втыкать страну, а иначе бы пришлось делать коллекции для одного-единственного товара чтобы у него страна появилась. Там товары в коллекции могут отличаться размером, цветом и даже дизайном, но коллекции как таковые вообще не выводятся, они только обеспечивают связь между товарами по cid. Скрипт получает товар, смотрит его cid, если он не null, скрипт запрашивает все товары с таким же cid кроме того который он получил - что нашлось, то выводится как "другие товары коллекции". |
Цитата:
Не надо тут блистать познаниями, и устраивать дебаты между нами, это спам в топике будет, который ему пользы не принесет. Вот когда он поймет, что эта структура базы данных и самое главное почему эта означает 99% успеха в проекте, вот это можно сказать, что это познания "не под копирку слов чужих". Будь это топик человека уже знающего тему, вот тогда можно было бы нам с тобой лабуду тут разводить. Но ведь это как факт, что львиная доля начинающих начинает на каких-то мультиках, вот и результат - увидел, скопировал, работает, а то, что вся работа построена на безобразном коде, такой ученик не понимает. Эти два последних твоих поста, это гут, ведь можно же деловым языком писать, без жаргона пижонского? ) Ну а судя по частоте твоих постов времени у тебя много, вот донести до него это, но не по принципу "делай как я", иначе толку от этого не будет, и надо начинать с простого. А я занят как раз разгребанием кошмарной базы данных заказчика. Кошмарный код, одни комментарии к которому можно как анекдоты в сети выставлять. Такое как раз и пишут те, что "под копирку" работают, совсем не задумываясь о том, что за всем этим кроется. Но самое ужасное то, что мне еще приходится убеждать заказчика, что нет, этого так нельзя оставлять, и почему нельзя, и это при том, что он понимает - все, что у него сейчас есть, это дерьмо... |
Специально для облегчения судеб таких как вы и придуман сайт govnokod.ru отпостите туда смишное от заказчика.
Я влез потому что прошел примерно такой же путь в начале которого сейчас автор темы. На каком запасном пути стоит ваш бронепоезд, я до сих пор не понял. Похоже кроме листания книжек в твердых переплетах ничего более вещественного в этом домене вы не реализовали. Практики вообще нуль. Откуда вообще берутся трудности проектирования баз данных для сущностей и моделей которые веками известны и отработаны? Вопрос риторический. Оттуда-же, откуда вообще трудности перевода. Приходится переводить с человеческой культуры на машинную культуру и так, чтобы сохранить полностью смысл, а то и нового добавить по смыслу. Даже взяв в плен товароведа и всех остальных работников магазина придется долго пытать их каленым железом чтоб узнать как они понимают, как работают, что полезное, что вредное и все такое. А вы думали внедрежом 1с люди занимаются за хорошие деньги просто так? И кстати лучшие внедреженцы из тех самых товароведов, которые освоили проектирование и программирование. |
Да, в этой теме вы laimas показали свою интеллигентскую сущность. Интеллигент это человек небельмеса в вопросе, но начитавшийся предисловий и умеющий заковыристо повторять за собеседником то же самое, другими словами и более развернуто, с цитатами, с глубокими мыслями. Создавая впечатление профессионала и одновременно никак не информируя визави, интеллигент добивается вечной зависимости собеседника от своих пустых речей. Человек никогда не поумнеет общаясь с интеллигентом и самостоятельно ничего не сделает, просто потому что не научился ничему в этом общении. Самое злое что и вместе с интеллигентом он ничего не сделает, ибо интеллигент вовсе не специалист, который так же ставит в зависимость от себя людей, но специалист хотя бы за них все и делает. И - никогда ничего не делает, а только молотит о высшем.
|
kostyanet, попробовал разобраться в вашем коде с тремя таблицами, со списком, в принципе вышло. А в корзину попадает товар по старому, Array ( [2] => 3 [3] => 1 ) . Идёт перезапись старого размера новым. Карточка товара пока всё равно выводится таким образом:
<table align="center" style="border-width: 1; border-style: dashed" class="product" width="200" height="200">
<tr>
<td valign="top" align="center" cellpadding="5" cellspacing="5">
<div><a href="#"><img src="userfiles/<?=$product['image']?>" width="150" height="100" alt="" /></a></div>
<div class="description">
<div class="product-name"><a href="#"><?=$product['title']?></a></div>
<div class="product-price">Цена: <?=$product['price']?> руб</div>
</div>
</td>
<td valign="top">
<div><?=$product['description']?></a></div>
<form action="index.php" method="get">
<fieldset> Размер:
<input type="hidden" name="view" value="add_to_cart">
<input type="hidden" name="id" value="<?=$product['id']?>">
<select name="size">
<?php
$result = $link->query("select
`p`.`title`,
`s`.`size`
from `relations` as `r`
left join `products` as `p`
on `p`.`id`=`r`.`products_id`
left join `sizes` as `s`
on `s`.`id`=`r`.`size_id`
where `r`.`products_id`='$id' ");
while ($b = mysqli_fetch_assoc($result))
{
echo "<option value='".$b['size']."'>" .$b['size']. " </option>";
}
?>
</select></fieldset>
<input type=image src="userfiles/8.jpg" width="60" height="60" value="Добавить в корзину">
</form>
</td>
</tr>
</table>
И размеры попадают в корзину через сессию:
case('add_to_cart'):
$id = $_GET['id'];
$size = $_GET['size'];
$_SESSION['cart_size'][$id] = $size;
$add_item = add_to_cart($id);
$_SESSION['total_items'] = total_items($_SESSION['cart']);
$_SESSION['total_price'] = total_price($_SESSION['cart']);
header('Location:index.php?view=product&id='.$id);
break;
laimas объяснял, что нужно заносить в массив эти данные, но пока на практике получился "ноль"... Так и не допёр, что за $escaped_quoted_path, точнее зачем это нужно и как выоводить - select * from model where path = $escaped_quoted_path;? И то же самое с $res['id'] в prods.model_id = $res['id']..... |
kostyanet
Моя практика говорит о том, что под тот базис, что есть у автора, много чего ты ту вещал, это выстрелы в холостую. Послушаешь таких речей, так надо писать учебники начиная с ООП, причем не поясняя вообще что это и что дает, и заканчивая приоритетами операторов. Не понимаешь ты этого, просто заносит тебя в понос, пальцы растопырил и .... Было бы все так просто, были бы все гениями. А что я могу, какая практика, это не суть важного, пост не моей личности посвящен, не моим проблемам, и базарить об этом, в чужих темах, это спам и неуважение к остальным. |
Полвечера сражаюсь с кодировкой "utf8mb4_general_ci". Нашёл подсказку на англоязычном сайте, пришлось немного поменять код в файле "DatabaseInterface.class.php". Теперь хоть ошибки на английском....
|
Цитата:
Вот вся сущность поста:
case('add_to_cart'):
$id = $_GET['id'];
$size = $_GET['size'];
$_SESSION['cart_size'][$id] = $size;
$add_item = add_to_cart($id);
$_SESSION['total_items'] = total_items($_SESSION['cart']);
$_SESSION['total_price'] = total_price($_SESSION['cart']);
header('Location:index.php?view=product&id='.$id);
break;
Толку трещать о высоких материях, если пока простых вещей не знаем. Надоели вы, горе "учителя" до нельзя. arhat78, Простой вопрос - есть массив А, есть массив В, как можно, ну или правильнее какими средствами можно элементы/значения массива В добавить в массив А? |
laimas, вот это простое сложение двух массивов: $result = $arrayА + $arrayВ; есть ещё функция array_merge;
Но у меня есть ещё (может и лишние функции вычисления total_items, total_price):
function total_items($cart)
{
$num_items = 0;
if(is_array($cart))
{
foreach($cart as $id => $qty)
{
$num_items += $qty;
}
return $num_items;
}
}
function total_price($cart)
{
$total_price = '0.00';
global $link;
if(is_array($cart))
{
foreach($cart as $id => $qty)
{
$result = $link->query("SELECT price FROM products WHERE id='$id' ");
if($result)
{
$item_price = mysqli_fetch_assoc($result);
$total_price += $item_price['price'] * $qty;
}
}
return $total_price;
}
}
?>
И add_to_cart (уже показывал эту бедную на функционал функцию):
function add_to_cart($id, $size)
{
if(isset($_SESSION['cart'][$id]))
{
$_SESSION['cart'][$id]++;
return true;
}
else
{
$_SESSION['cart'][$id] = 1;
return true;
}
return false;
}
|
Цитата:
Но есть одна интересная деталь в поведении массивов при $arrayА + $arrayВ и array_merge(). Если ключи массива цифровые (индексный массив), то в первом случае ключи массива А, которые имеются и в массиве В будут перезаписаны его значениями, а при использовании array_merge() нет. И эту особенность ведь тоже можно использовать. А в случае строковых ключей в обоих случаях результат будет одинаков. А есть еще функции пересечения/расхождения массивов, а так же замены array_replace и array_replace_recursive. В общем набор большой, и общелкать какой-то массив проблем нет. Проблема ваша в другом - в корзину попадает товар по старому, Array ( [2] => 3 [3] => 1 ) А по по новому тогда как? Я вам задавал вопросы и не раз - как планируется торговать, как будут набираться товары, поштучно или же можно набирать количество (это по мимо размеров)... Не на один вопрос я ответа не видел. А ведь с того надо начинать. И чтобы не переписывать код обслуживающий корзину, взаимодействия клиент-сервер нужна такая структура таблицы, которая бы позволяла добавлять в нее элементы описывающие какие-то доп. характеристики товара, но код при этом нужно будет не переписывать. Все что я писал, это лишь примеры. Я мог бы и так написать - сервер получает от клиента такой массив описывающий выбор - Array(125, 42, 41). Можно и так, но это уже совсем иное, и иные правила торговли ботинками. Не надо просто копировать, не научитесь вы так ничему. Тогда уж не учится, а плюнуть на все это, у хотстера оплатить услугу "конструктор магазина", сконструировали и торгуем ботинками. Просто и голова не болит. :) |
Так я же не просто "копирую". За год я понимаю практически весь код, который написан. А вот новые подходы, которые вы показываете-подсказываете - пока тяжело даются. Я давал ссылку на магазин - там вроде как понятно, как выбирается ботинок и размеры к нему. И я не для коммерческих целей этим занимаюсь. Примерно год назад решил попробовать, что это такое за РНР и получится ли. Заинтересовало. Я этим занимаюсь в свободное от работы время, и чисто для себя.
|
Да, я помню об этой ссылке, да, был там. Но ведь вопрос возник какой - как быть, если размеров не один а несколько? И тут началось....
Не надо копировать, это примеры и их надо разбирать, я же не пишу их под конкретный ваш скрипт. Забросьте на время этот магазин, и сделайте проще - одну страницу, в которой и РНР код и html. Базу товаров на этой странице имитируйте обычным массивом - первичные ключи его, это ID товаров, а массивы под ними, это размеры и цена товара. Думаю не сложно такой массив вывести как списки в форме в котором можно выбрать эти размеры. РНР код также принимает форму, записывает полученное в сессию как корзину, и результаты работы над массивами выводит на экран, что позволяет и проследить, и понять "а так ли работает, как я хочу". Этого то ведь будет достаточно чтобы усвоить наконец-то инструменты РНР работы с массивами или нет? Думаю, что да. Когда будете использовать этот "учебный" скрипт задайтесь вопросом - будет ли удобно, если выбор одного размера одного товара, это отправка формы и $_SESSION['cart_size'][$id]++ или же нет, и вообще почему $_SESSION['cart_size'] это вообще нечто отдельное, а не как часть корзины и определяющая характеристики товара выбранного покупателем. Если действительно думать, то обязательно придет понимание того, что выбор товара по одному еще может быть в случае отправки параметров выбора Ajax, а в случае отправки формы непосредственно, это крайне неудобно для покупателя. Вот тут и должно прийти понимание формата данных которые должен принимать сервер от покупателя. Думаю, что должно прийти, если задумываться. Больше я не знаю что еще сказать, ведь об одном и том же уже какой раз говорится. |
| Часовой пояс GMT +3, время: 03:21. |