[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: каталог магазина, размеры HELP
ED24567
Озадачили сделать ИМ с массой прибамбасов, со всем разобрался кроме вывода доступных размеров в каталоге: как пример ( 42...52)
user posted image
Основной затык - количество этих размеров, названия- произвольно задаются админом ИМ. У каждого продукта - произвольная комбинация доступных размеров.
Какая должна быть структура базы под эти размеры, каким запросом за раз получить для каталога характеристики товара - основной затык - доступные размеры, все остальное - не принципиально.
Хоботить несколько запросов, потом разбирать php - как-то скучно
arbuzmaster
Можно сделать и одну таблицу просто в ней указать все размеры по порядку а в качестве наличия размера значения (0/1) или разделить таблицу на две - в одной тавары в другой размеры и объеденить их через id Но по бльшому счету мне кажется это не принципиально. Есть еще вариант указывать все размеры в одном столбце чере разделитель (запятую например) но, в последствии можно нарваться на какой нибудь гемморой ! В общем жди сейчас гурру прийдут, может чего дельного еще подскажут wink.gif

_____________
Мой первый сайтик

Посмотри на свой XBMC под другим углом
ED24567
указать все размеры по порядку в доп. полях - неа , Основная суть - через админку сайта блондинка может добавлять новые размеры, грубо, были размеры 42-52 , захотелось добавить X L S M - и что дальше? Переписывать админку, запросы... Не вариант совсем.

Хранить в одной ячейке все доступные размеры, с разделителем - запятая - ГИМОР

--------------------
Одна ячейка - одно значение, Количество размеров - управляемо из админки.
waldicom
Можно подумать в такую сторону:
таблица products и таблица details. В details хранятся варианты (размеры, цвета, длина, ширина). Связь таблиц по ключу из products. Таким образом достигается еще и то, что у каждого размера есть свой номер артикля.

_____________
Свои мозги еще никто не отменял.
Телепатов нету.
arbuzmaster
Waldicom дело говорит, только я думаю что во второй табличке должно быть так id|size|key иначе цвет длина ширина будут повторяться бессмысленно

_____________
Мой первый сайтик

Посмотри на свой XBMC под другим углом
ED24567
Спасибо всем ответившим, Примерно разобрался, дальше сам, длина/ширина - это уже детали
arbuzmaster
Ну в общем получается так примерно
products
id|name|count|......|key|
sizes
id|size|show|key
то есть в таблице sizes для каждого товара будут все размеры которые туда добавят. wink.gif

_____________
Мой первый сайтик

Посмотри на свой XBMC под другим углом
SlavaFr
Цитата (waldicom @ 15.02.2018 - 15:46)
Можно подумать в такую сторону:
таблица products и таблица details. В details хранятся варианты (размеры, цвета, длина, ширина). Связь таблиц по ключу из products. Таким образом достигается еще и то, что у каждого размера есть свой номер артикля.

Так точно.

Дополнительно должна быть таблица с данными в складе. То есть если модел "Х" имеет на складе размер 45 и 50, то только эти размеры будут показаны, как имеющимеся.

То есть связь между продук-детали и складом по модели.


_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();
waldicom
Цитата (SlavaFr @ 22.02.2018 - 11:45)
Цитата (waldicom @ 15.02.2018 - 15:46)
Можно подумать в такую сторону:
таблица products и таблица details. В details хранятся варианты  (размеры, цвета, длина, ширина). Связь таблиц по ключу из products. Таким образом достигается еще и то, что у каждого размера есть свой номер артикля.

Так точно.

Дополнительно должна быть таблица с данными в складе. То есть если модел "Х" имеет на складе размер 45 и 50, то только эти размеры будут показаны, как имеющимеся.

То есть связь между продук-детали и складом по модели.

Пока не увидел необхоимость в отельной таблице для наличия на складе? Почему бы не ввести поле inStock в таблицу details?

_____________
Свои мозги еще никто не отменял.
Телепатов нету.
AllesKlar
Цитата (waldicom @ 15.02.2018 - 17:46)
Можно подумать в такую сторону:
таблица products и таблица details. В details хранятся варианты (размеры, цвета, длина, ширина). Связь таблиц по ключу из products. Таким образом достигается еще и то, что у каждого размера есть свой номер артикля.

именно так реализовано, например, в OsCommerce

_____________
[продано копирайтерам]
SlavaFr
Цитата (waldicom @ 22.02.2018 - 11:06)
Пока не увидел необхоимость в отельной таблице для наличия на складе? Почему бы не ввести поле inStock в таблицу details?

В принципе на первых порах можно так, как ты предложил.
Но потом рано или поздно приходится расширять логику на "склад".

_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();
waldicom
Цитата (SlavaFr @ 22.02.2018 - 13:07)
Цитата (waldicom @ 22.02.2018 - 11:06)
Пока не увидел необхоимость в отельной таблице для наличия на складе? Почему бы не ввести поле inStock в таблицу details?

В принципе на первых порах можно так, как ты предложил.
Но потом рано или поздно приходится расширять логику на "склад".

а, в смысле если несколько складов? Тогда конечно да.

_____________
Свои мозги еще никто не отменял.
Телепатов нету.
SlavaFr
Цитата (waldicom @ 22.02.2018 - 13:01)
а, в смысле если несколько складов? Тогда конечно да.

гораздо раньше.
Например когда интересует когда доставили товар, кто доставил товар, когда товар был заказан, когда товар дозлжен прибыть на склад. За сколько был куплен товар и т.д. Сколько товара было !заререзрвированно!, сколько отправлено, сколько прислано назад...


_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();
waldicom
Цитата (SlavaFr @ 22.02.2018 - 17:02)
Цитата (waldicom @ 22.02.2018 - 13:01)
а, в смысле если несколько складов? Тогда конечно да.

гораздо раньше.
Например когда интересует когда доставили товар, кто доставил товар, когда товар был заказан, когда товар дозлжен прибыть на склад. За сколько был куплен товар и т.д. Сколько товара было !заререзрвированно!, сколько отправлено, сколько прислано назад...

Это все не интересует магазин. Магазин продает - Warenwirtschaft осуществляет менеджмент.

_____________
Свои мозги еще никто не отменял.
Телепатов нету.
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.