Организация структуры БД интернет-магазина: цена товара зависит от его параметров.

[shtogrin]

Navarro
Создавать для каждой характеристики свою таблицу не серьезно. А если 50 групп товаров и в каждой группе 10 характеристик, создавать 500 таблиц?

Гриша К.
Не надо привязывать цены к характеристикам! Если товары отличаються размером, это разные товары, с разным артикулом и своей ценой. Думай еще о том, что надо хранить продажи и вычислять их стоимость. Характеристики нужны для описания товара, для создания интерфейса выбора.

 

[_vampiro_]

ИМХО это все полный ... Маразм.
опция (параметр) размер, при цвете "голубой" будет иметь НЕ ТУ цену, которая будет при цвете "белый", потому что метр голубого цвета стоит больше, чем метр белого. Соответственно, надо для параметра "размер" кроме цифрового значения (метр на метр) прописывать и значения остальных параметров, при которых эта цена действительна.

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

размерИД, цветИД, типИД, цена.

хотя эта запись от "диван синий 2 на 3, 1000" будет отличатся не сильно. Поиск чуть дольше, зато добавлять товары легче на много.

 

[Гриша К.]

Navarro, спасибо за пояснения, всеравно сложновато понять, но я с вашим примером теперь смогу самостоятельно разобраться.

shtogrin,
Если привязывать цены к товару, то получается, что например есть матрас, он имеет 30 размеров, и 2 цвета, получается 60 вариантов, т.е. я должен буду ввести 60 раз одинаковео, название, описание товара, фотографию и потом вывести 60 товаров?
Можете привести пример вашего варианта?

_vampiro_, вас я не совсем понимаю.
В приведенном мною примере, цена определяется как раз например, для размера и цвета, если есть 30 размеров и 2 цвета, то цена определяется для всех 60 вариантов, а название, описание и фото товара одно.
Товары могут иметь совершщенное разные характеристик: размер, цвет, обшивка, жесткость, модель, набивка, и т.д. И у новых товаров могут быть совершенно новые характеристики, поэтому я и ищу вариант, дающий возможность добовлять новые зхарактеристики, и определять цены для набора характеристик (размер 1 + цвет1 + обшивка1 = цена: 1000).
Приведенный мной вариант решения, я сейчас начинаю пробовать, как записывать данные в БД, как осуществлять поиск, как извлекать и т.д.

 

[_vampiro_]

Гриша К.
желательно 60 вариантов, но можно 2 варианта, если хранить "множества" параметров.

-~{}~ 22.06.06 14:40:

кстати, фоты-то действительно надо разные... + наличие товара можно привязать только при такой схеме.

 

[Гриша К.]

_vampiro_, фото для 60 вариантов как раз одно (Ну для одного товара может как раз быть несколько вариантов фотографий, ну и для всех 60 вариантов тоже самое).
Вот посмотрите пример: http://magazin.pozvonochnik.info/pages/sealy/sealy5.php
А представте сколько вариантов в данной примере, наверное около 200, ну и надо мне вводить 200 раз одно и тоже описание и анзвание и фото, а если у меня 20 новых товаров, то получается 4000 раз вводить все это, да это ужас. Как раз так я уже делал и представляю что это такое.

 

[_vampiro_]

Гриша К.
на пальцах:
вам (в вашем примере) придется заполнять PARAMETERS_SELECT 200 раз. (или не так?)
все, что вам надо сделать - это "автоматизировать заполнение".

Даю мысль:
поле "тип товара" - select из всех.
все параметры - либо списки с мультиселект, либо таблички с "чекбоксами". Вы выбираете возможные зачения для всех параметров, указываете цену - и добавляется куча записей с разными параметрами и одинаковой ценой.

Проблема же только в добавлении?

 

[Гриша К.]

_vampiro_,
PARAMETERS_SELECT 200 раз - да это действительно так.

По поводу полученной мысли:
товары у меня делятся на категории (матрасы -> пружинные), т.е. при добавлении товара извлекаю все уже существующие параметры (размер, цвет) в select
И из них выбиарю (чтобы не писать), если надо ввожу новые?

Да проблема в добавлении.

Я вас правильно понял?

 

[shtogrin]

Автор оригинала: Гриша К.
Если привязывать цены к товару, то получается, что например есть матрас, он имеет 30 размеров, и 2 цвета, получается 60 вариантов, т.е. я должен буду ввести 60 раз одинаковео, название, описание товара, фотографию и потом вывести 60 товаров?
Можете привести пример вашего варианта?

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

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

 

[Гриша К.]

shtogrin, спасибо за пояснение.
Если вы предлагаете тоже, описание и название и фото, в одну таблицу, то что тогда вы имеете ввиду по 60 разными товарами это артикулы?
Вот артикулы как раз у 60 вариантов одни и теже (например для БН3-26/2), потому что это один товар, но он имеет разные цены, которые заисят от размера, но это не для всех товаров, для некоторых цена одна, независимо от размера, и это все в одно магазине, вот и получается каламбур блин.

 

[_vampiro_]

ну, "пружинные" - это тоже параметр.

тип товара: [подушка] (тут список "матрац", "подушка", "кресло")

цена товара: [20000] (тектовое поле)
фото :   [                   ] [обзор...]
---параметры----
размеры:

10-10 [ ]
10-20 [ ]
10-30 [x]
20-20 [x]
20-30 [x]
[добавить размер]

цвета
белый [ ]
синий [x]
[добавить цвет]

и т.д.

-~{}~ 22.06.06 15:17:

на примере добавляем 3 подушки синих с разными размерами и одной ценой.

 

[Гриша К.]

_vampiro_,
да я вас понял, спасибо.

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

(Пружинный это не параметр, так как у пружинных и непружинных матрасов, разные фотографии, разное описание и название и артикулы).

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

 

[shtogrin]

Автор оригинала: Гриша К.
Если вы предлагаете тоже, описание и название и фото, в одну таблицу, то что тогда вы имеете ввиду по 60 разными товарами это артикулы?
Вот артикулы как раз у 60 вариантов одни и теже (например для БН3-26/2), потому что это один товар, но он имеет разные цены, которые заисят от размера, но это не для всех товаров, для некоторых цена одна, независимо от размера, и это все в одно магазине, вот и получается каламбур блин.

Я же написал хранить путь к каталогу с описанием, зачем картинки в базу пихать. Тогда несколько товаров могут иметь одинаковое описание

product_id
product_name
product_code
product_path_for_description

/description/BHZ/photo_small.jpg, photo.jpg

Как они считают в офисе и на чем???

 

[Гриша К.]

shtogrin, в базе будут только названия фотографий, а вообще у меня будет дополнительная таблица:
PHOTOS (photo_id, product_id)
Соотвественно фотографии буду храниться на сервере (и иметь имя в виде ИД фотографии):
/photo/small/1.jpg
/phot/1.jpg

Как они считают в офисе и на чем???

Не понял вашего вопроса

 

[_vampiro_]

Гриша К.
1С, Парус, Галактика, ODBS... в какой программе ведется складской учет на предприятии?

 

[Гриша К.]

_vampiro_, сотрудничаем с разными фирмами, считают всЁ они, у одних 1С, у других вообще ничего, у кого-то что-то еще.
Я даже и незадумывался об этом.
А неподскажите ли для чего это хорошо было бы знать, при разработке интернет-магазина?

 

[_vampiro_]

Гриша К.
чтобы они тебе кидали DBF с приходами за день прям в скрипт, а скрипт его подгружал в магазин сразу. и ты не парился бы с ручным вводом.

 

[shtogrin]

_vampiro_
Спасибо, объяснили человеку.

Гриша К.
Если интегрировать проект с существующими решениями заказчика, вы избавите их от дублирования работы по созданию каталога товаров и дополнительному обновлению цен на сайте. Рассматривайте вначале вариант импорта-экспорта через файл. Это заодно решит проблему с первоначальным наполнением каталога на сайте.

 

[asm]

Гриша К.
не понимаешь

 

[Гриша К.]

_vampiro_, shtogrin спасибо за объяснения, но для меня конечно это сложно, понимаю частично вас (и конечно же это сейчас сразу непонять, надо мне почитать информацию об этом, незнаю какую только). Возможно вы знаете ссылки на статьи?
Вообще, фирм с которыми мы сотрудничаем и собираемся, много, у каждой свои метод работы.
У нас есть один отлаженный метод работы, когда мы посылаем фирме артикул и кол-во товара (не только это, но это главное), они вбивают в свою базу артикул (5-10 символов и кол-во товара), у них по совей базе формируется свой № заказа и т.д.
Другие вообще записывают в exel, потом считают и т.д.
А под электронную комерцию вообще никто из них не подстроен.

asm, напишите пожалуйста, что я не понял.

 

[Navarro]

Автор оригинала: shtogrin
Navarro
Создавать для каждой характеристики свою таблицу не серьезно. А если 50 групп товаров и в каждой группе 10 характеристик, создавать 500 таблиц?

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