Отправляет email-рассылки с помощью сервиса Sendsay

За 2005-06-15

Re: Каталог продукции

Hello, Begemot!

On Tue, 14 Jun 2005 14:23:50 +0400 you wrote:

> > 1 таблица имена разделов: у нее 3 основных параметра:
> > 1. номер (id);
> > 2. на какой раздел ссылается (номер id). У
> > основных разделов этот параметр равен 0;
> > 3.Имя раздела.
> > 2 таблица со значениями: содержит столбец, который указывает на
> > id-раздела таблицы 1.
>
> > При добавлении нового раздела, добавляй его в 1 таблицу, а его номер
> > по порядку (id) давай как ссылку в таблицу 2. Если хочешь установить
> > как подраздел, то в (2) укажи id родительского каталога.
>
> Так-то оно так и у меня так сделано (нуц почти так у меня еще
> несколько полей). Твоя схема тоже не решает проблемы. Мне же нужно
> сделать чтобы на раздел добавлялось произвольное количество свойств
> товаров, данного раздела. Причем свойства могут быть нескольких типов
> - число, строка, перечисляемый тип и т. д. Т. е., например, раздел
> "Сотики" и для него задаются свойства: размер, цвет, стандарт, цена
> и т. д. А для следующего раздела свойства будут уже другими.
> Вот в чем проблема.

А почему бы не сделать поле типа BLOB, в котором будет описание товара?
К примеру:
Color='красный'
Vendor='Morotola'
Model='С650'

Описания структуры можно положить в отдельную таблицу.
Скажем такого вида:
...
rid INT //id раздела
k VARCHAR ( 20 ) //ключ, к примеру Color, Vendor и т.д.

К примеру имеется раздел с id=1 (мобилы) и раздел с id=2 (одежда) и
такая таблица:
#id key
1 Color
1 Model
1 Vendor
2 Size
2 Vendor
2 Color
2 matherial

   "B." 2005-06-15 22:31:15 (#385522)

Re: Каталог продукции

Hello, Begemot!

On Tue, 14 Jun 2005 14:23:50 +0400 you wrote:

> > 1 таблица имена разделов: у нее 3 основных параметра:
> > 1. номер (id);
> > 2. на какой раздел ссылается (номер id). У
> > основных разделов этот параметр равен 0;
> > 3.Имя раздела.
> > 2 таблица со значениями: содержит столбец, который указывает на
> > id-раздела таблицы 1.
>
> > При добавлении нового раздела, добавляй его в 1 таблицу, а его номер
> > по порядку (id) давай как ссылку в таблицу 2. Если хочешь установить
> > как подраздел, то в (2) укажи id родительского каталога.
>
> Так-то оно так и у меня так сделано (нуц почти так у меня еще
> несколько полей). Твоя схема тоже не решает проблемы. Мне же нужно
> сделать чтобы на раздел добавлялось произвольное количество свойств
> товаров, данного раздела. Причем свойства могут быть нескольких типов
> - число, строка, перечисляемый тип и т. д. Т. е., например, раздел
> "Сотики" и для него задаются свойства: размер, цвет, стандарт, цена
> и т. д. А для следующего раздела свойства будут уже другими.
> Вот в чем проблема.

А почему бы не сделать поле типа BLOB, в котором будет описание товара?
К примеру:
Color='красный'
Vendor='Morotola'
Model='С650'

Описания структуры можно положить в отдельную таблицу.
Скажем такого вида:
...
rid INT //id раздела
k VARCHAR ( 20 ) //ключ, к примеру Color, Vendor и т.д.

К примеру имеется раздел с id=1 (мобилы) и раздел с id=2 (одежда) и
такая таблица:
#id key
1 Color
1 Model
1 Vendor
2 Size
2 Vendor
2 Color
2 matherial

   "B." 2005-06-15 22:31:08 (#385521)

Re[11]: Каталог продукции

Здравствуйте, Begemot.

> Я думаю XML, здесь не подходит... Т. к. в каталоге планируется сделать
> сравнение товаров по некоторым параметрам, а с XML'ем, на мой взгляд,
> здесь получиться большой геморой.

Если сравнение нужно делать из, скажем, 100 наименований, то нет
ничего сложного прочитать 100 записей, получить 100 xmlек, обработать
их скриптом и выдать результат. Если, конечно, наименований больше, то
придётся просто делать очень широкую таблицу со всеми возможными
вариантами полей-параметров.

   Andrey Yakushev 2005-06-15 20:50:08 (#385429)

Re[9]: Каталог продукции

Здравствуйте, Пашка.

Значения параметров храняться в таблицах Option. Таких таблиц семь
(соответственно количеству типов параметров), т. е. таблица string,
int, picture и т. д. Я на схеме их обозначил одной таблицей Option(N)
- рисовать лень было. Я думаю после данного разъяснения сразу
становиться понятным различие между ID и Option_ID. А возможные
значения перечисляемого типа храняться в поле select таблицы
Category_option, я в схеме просто забыл указать данное поле. Это не
очень верно, зато избавляет от лишниш проблем.

> Привет, Бегемот!

> А где значения параметров? А где возможные значения у перечислимого
> типа? А еще в Option есть ID и Option_ID. Чем они отличаются? А еще
> наверняка есть такая штука, что у числовых типов должны задаваться
> границы изменения...

> Пашка

> 15 июня 2005 г., 10:15:15, Begemot <begemotina20***@m*****.ru> wrote:

>> Здравствуйте, Andrey.

>> Итак, предлогаю на суд всех читателей, структуру моей базы данных
>> каталоога товаров.
>> Напомню ТЗ: в каталоге должны создаваться подразделы бесконечной
>> вложенности. Для каждого раздела можно задавать произвольное
>> количество свойств, т. е. при добавлении товара в данный раздел ему
>> (товару) заполняются поля данных свойств. (получилось сумбурно, но
>> надеюсь разберете).

>> И еще маленькое пояснение. База данных MySQL, тип базы данных InnoDB.
>> Вот здесь-то и возникает колизия... т. к. связи образуют кольцо.
>> Или я ошибаюсь???

>> >> | Category | |Category_option |
>> |---------------| |----------------|
>> --| ID |---| |ID |---|
>> | | Parent_ID | |-----|Cat_ID | |
>> | | Name | |Title | |
>> | | Sort | |Type | |
>> | |_______________| |________________| |
>> | |
>> | |
>> | |
>> | |
>> | | Product | | Option(N) | |
>> | |---------------| |----------------| |
>> | | ID |---| |ID | |
>> |-| Cat_ID | |-----|Item_ID | |
>> | Name | |Option_ID |---|
>> | Picture | |Type |
>> | Description | |________________|
>> | Sort |
>> |_______________|

>>> Здравствуйте, Begemot.

>>> Вы писали 14 июня 2005 г., 15:58:05:

>>>> Андрей, привет!
>>>> СУПЕР!!! Спасибо за идею!!! И как сам не додумался... Ты прав с XML
>>>> это проблема должна решиться. С завтрашнего дня, наверное, начну
>>>> реализовывать, а получится или нет будет видно. Но еще раз спасибо за
>>>> идею!

>>> Идея-то лежит на поверхности. Просто когда говорят о данных, имеют в
>>> виду то, что с этими данными должна работать БД, должны делаться
>>> какие-то запросы, какой-то анализ. Если тебе этого не нужно, то
>>> велком! А если придётся эти разношёрстные данные анализировать и по
>>> ним делать запросы, то ты упрёшься головой в небо.





> библиотекa сайтостроительства http://www.i2r.ru/static/244/

   2005-06-15 20:02:19 (#385399)

Re[10]: Каталог продукции

Здравствуйте, Andrey.

Я думаю XML, здесь не подходит... Т. к. в каталоге планируется сделать
сравнение товаров по некоторым параметрам, а с XML'ем, на мой взгляд,
здесь получиться большой геморой.

> Здравствуйте, Бегемот.

> :( Не получил предыдущее письмо (почему-то). Поэтому прочитал по
> цитированию...

>> Итак, предлогаю на суд всех читателей, структуру моей базы данных
>> каталоога товаров.
>> Напомню ТЗ: в каталоге должны создаваться подразделы бесконечной
>> вложенности. Для каждого раздела можно задавать произвольное
>> количество свойств, т. е. при добавлении товара в данный раздел ему
>> (товару) заполняются поля данных свойств. (получилось сумбурно, но
>> надеюсь разберете).

> Не понимаю, зачем так сложно?
> У меня всё крутится на двух таблицах:
> http://www.kordon-rnd.ru/equipment/

> 1 - дерево
> id int(10) unsigned NOT NULL auto_increment,
> id_up int(10) unsigned default NULL,
> leaf enum('N','Y') NOT NULL default 'Y',
> name varchar(128) NOT NULL default '',
> visible enum('N','Y') NOT NULL default 'Y'

> 2 - описание элементов
> id_tree int(10) unsigned NOT NULL default '0',
> short varchar(255) NOT NULL default '',
> price1 float(15,2) unsigned default NULL,
> price2 float(15,2) unsigned default NULL,
> price3 float(15,2) unsigned default NULL,
> currency tinyint(3) unsigned default NULL,
> picture_big blob,
> picture_small blob,
> producer smallint(5) unsigned default NULL,
> link varchar(64) default NULL,
> description text,

> (На самом деле - 4; там ещё список производителей и список валют). Но
> дело не в этом. Дело в том, что каждый элемент дерева может быть либо
> веткой, либо листом. Вообще, это легко проверить: делается запрос на
> то, ссылается ли кто-нибудь на этот элемент как на родителя. Но это
> долго делать при показе. Поэтому я делаю это лишь при вводе или
> изменении данных, и устанавливаю флаг leaf. Вот и всё. А вторая
> таблица - описание элемента дерева. Вот тут уже ставь, что хочешь. А в
> одном из текстовых полей вставляй xml.

   2005-06-15 19:12:15 (#385382)

Re[9]: Каталог продукции

Здравствуйте, Бегемот.

:( Не получил предыдущее письмо (почему-то). Поэтому прочитал по
цитированию...

> Итак, предлогаю на суд всех читателей, структуру моей базы данных
> каталоога товаров.
> Напомню ТЗ: в каталоге должны создаваться подразделы бесконечной
> вложенности. Для каждого раздела можно задавать произвольное
> количество свойств, т. е. при добавлении товара в данный раздел ему
> (товару) заполняются поля данных свойств. (получилось сумбурно, но
> надеюсь разберете).

Не понимаю, зачем так сложно?
У меня всё крутится на двух таблицах:
http://www.kordon-rnd.ru/equipment/

1 - дерево
id int(10) unsigned NOT NULL auto_increment,
id_up int(10) unsigned default NULL,
leaf enum('N','Y') NOT NULL default 'Y',
name varchar(128) NOT NULL default '',
visible enum('N','Y') NOT NULL default 'Y'

2 - описание элементов
id_tree int(10) unsigned NOT NULL default '0',
short varchar(255) NOT NULL default '',
price1 float(15,2) unsigned default NULL,
price2 float(15,2) unsigned default NULL,
price3 float(15,2) unsigned default NULL,
currency tinyint(3) unsigned default NULL,
picture_big blob,
picture_small blob,
producer smallint(5) unsigned default NULL,
link varchar(64) default NULL,
description text,

(На самом деле - 4; там ещё список производителей и список валют). Но
дело не в этом. Дело в том, что каждый элемент дерева может быть либо
веткой, либо листом. Вообще, это легко проверить: делается запрос на
то, ссылается ли кто-нибудь на этот элемент как на родителя. Но это
долго делать при показе. Поэтому я делаю это лишь при вводе или
изменении данных, и устанавливаю флаг leaf. Вот и всё. А вторая
таблица - описание элемента дерева. Вот тут уже ставь, что хочешь. А в
одном из текстовых полей вставляй xml.

   Andrey Yakushev 2005-06-15 16:18:17 (#385337)

Re[8]: Каталог продукции

Привет, Бегемот!

А где значения параметров? А где возможные значения у перечислимого
типа? А еще в Option есть ID и Option_ID. Чем они отличаются? А еще
наверняка есть такая штука, что у числовых типов должны задаваться
границы изменения...

Пашка

15 июня 2005 г., 10:15:15, Begemot <begemotina20***@m*****.ru> wrote:

> Здравствуйте, Andrey.

> Итак, предлогаю на суд всех читателей, структуру моей базы данных
> каталоога товаров.
> Напомню ТЗ: в каталоге должны создаваться подразделы бесконечной
> вложенности. Для каждого раздела можно задавать произвольное
> количество свойств, т. е. при добавлении товара в данный раздел ему
> (товару) заполняются поля данных свойств. (получилось сумбурно, но
> надеюсь разберете).

> И еще маленькое пояснение. База данных MySQL, тип базы данных InnoDB.
> Вот здесь-то и возникает колизия... т. к. связи образуют кольцо.
> Или я ошибаюсь???

> > | Category | |Category_option |
> |---------------| |----------------|
> --| ID |---| |ID |---|
> | | Parent_ID | |-----|Cat_ID | |
> | | Name | |Title | |
> | | Sort | |Type | |
> | |_______________| |________________| |
> | |
> | |
> | |
> | |
> | | Product | | Option(N) | |
> | |---------------| |----------------| |
> | | ID |---| |ID | |
> |-| Cat_ID | |-----|Item_ID | |
> | Name | |Option_ID |---|
> | Picture | |Type |
> | Description | |________________|
> | Sort |
> |_______________|

>> Здравствуйте, Begemot.

>> Вы писали 14 июня 2005 г., 15:58:05:

>>> Андрей, привет!
>>> СУПЕР!!! Спасибо за идею!!! И как сам не додумался... Ты прав с XML
>>> это проблема должна решиться. С завтрашнего дня, наверное, начну
>>> реализовывать, а получится или нет будет видно. Но еще раз спасибо за
>>> идею!

>> Идея-то лежит на поверхности. Просто когда говорят о данных, имеют в
>> виду то, что с этими данными должна работать БД, должны делаться
>> какие-то запросы, какой-то анализ. Если тебе этого не нужно, то
>> велком! А если придётся эти разношёрстные данные анализировать и по
>> ним делать запросы, то ты упрёшься головой в небо.





библиотекa сайтостроительства http://www.i2r.ru/static/244/

   2005-06-15 15:54:25 (#385328)

Re[8]: Каталог продукции

Кручу верчу - запутать хАчу :) Каша.

Какое-то свойство раздела
ID
название

Раздел
ID
ID_свойства_раздела
PID
название

Товар
ID
Название

Таблица, которая всё связывает
id
id раздела
id товара

Оно?

С помощью мускула, на мой взгляд, организовать дерево не возможно. Здесь
должна работать рекурсивная функция, переберая всё в таблице с разделами и
выстраивая дерево.

А вообще, лучше всё это на живом примере привести.

С уважением, Косарев Дмитрий

Исходное сообщение От: "Begemot" <begemotina20***@m*****.ru>
Кому: "inet.webbuild.webbuilding (2109226)" <adm***@e*****.ru>
Отправлено: 15 июня 2005 г. 10:15
Тема: Re[7]: Каталог продукции

> Здравствуйте, Andrey.
>
> Итак, предлогаю на суд всех читателей, структуру моей базы данных
> каталоога товаров.
> Напомню ТЗ: в каталоге должны создаваться подразделы бесконечной
> вложенности. Для каждого раздела можно задавать произвольное
> количество свойств, т. е. при добавлении товара в данный раздел ему
> (товару) заполняются поля данных свойств. (получилось сумбурно, но
> надеюсь разберете).
>
> И еще маленькое пояснение. База данных MySQL, тип базы данных InnoDB.
> Вот здесь-то и возникает колизия... т. к. связи образуют кольцо.
> Или я ошибаюсь???
>
> > | Category | |Category_option |
> |---------------| |----------------|
> --| ID |---| |ID |---|
> | | Parent_ID | |-----|Cat_ID | |
> | | Name | |Title | |
> | | Sort | |Type | |
> | |_______________| |________________| |
> | |
> | |
> | |
> | |
> | | Product | | Option(N) | |
> | |---------------| |----------------| |
> | | ID |---| |ID | |
> |-| Cat_ID | |-----|Item_ID | |
> | Name | |Option_ID |---|
> | Picture | |Type |
> | Description | |________________|
> | Sort |
> |_______________|
>
> > Здравствуйте, Begemot.
>
> > Вы писали 14 июня 2005 г., 15:58:05:
>
> >> Андрей, привет!
> >> СУПЕР!!! Спасибо за идею!!! И как сам не додумался... Ты прав с XML
> >> это проблема должна решиться. С завтрашнего дня, наверное, начну
> >> реализовывать, а получится или нет будет видно. Но еще раз спасибо за
> >> идею!
>
> > Идея-то лежит на поверхности. Просто когда говорят о данных, имеют в
> > виду то, что с этими данными должна работать БД, должны делаться
> > какие-то запросы, какой-то анализ. Если тебе этого не нужно, то
> > велком! А если придётся эти разношёрстные данные анализировать и по
> > ним делать запросы, то ты упрёшься головой в небо.
>
>
>
>
> --
> С уважением,
> Begemot mailto:begemotina20***@m*****.ru
>
>
>
>
>
> библиотекa сайтостроительства http://www.i2r.ru/static/244/
>
>
>





библиотекa сайтостроительства http://www.i2r.ru/static/244/

   2005-06-15 15:16:28 (#385298)

Re[7]: Каталог продукции

Здравствуйте, Andrey.

Итак, предлогаю на суд всех читателей, структуру моей базы данных
каталоога товаров.
Напомню ТЗ: в каталоге должны создаваться подразделы бесконечной
вложенности. Для каждого раздела можно задавать произвольное
количество свойств, т. е. при добавлении товара в данный раздел ему
(товару) заполняются поля данных свойств. (получилось сумбурно, но
надеюсь разберете).

И еще маленькое пояснение. База данных MySQL, тип базы данных InnoDB.
Вот здесь-то и возникает колизия... т. к. связи образуют кольцо.
Или я ошибаюсь???

| Category | |Category_option |
|---------------| |----------------|
--| ID |---| |ID |---|
| | Parent_ID | |-----|Cat_ID | |
| | Name | |Title | |
| | Sort | |Type | |
| |_______________| |________________| |
| |
| |
| |
| |
| | Product | | Option(N) | |
| |---------------| |----------------| |
| | ID |---| |ID | |
|-| Cat_ID | |-----|Item_ID | |
| Name | |Option_ID |---|
| Picture | |Type |
| Description | |________________|
| Sort |
|_______________|

> Здравствуйте, Begemot.

> Вы писали 14 июня 2005 г., 15:58:05:

>> Андрей, привет!
>> СУПЕР!!! Спасибо за идею!!! И как сам не додумался... Ты прав с XML
>> это проблема должна решиться. С завтрашнего дня, наверное, начну
>> реализовывать, а получится или нет будет видно. Но еще раз спасибо за
>> идею!

> Идея-то лежит на поверхности. Просто когда говорят о данных, имеют в
> виду то, что с этими данными должна работать БД, должны делаться
> какие-то запросы, какой-то анализ. Если тебе этого не нужно, то
> велком! А если придётся эти разношёрстные данные анализировать и по
> ним делать запросы, то ты упрёшься головой в небо.

   2005-06-15 13:33:36 (#385262)