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

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

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

Есть материалы для создания светотехнических изделий, эти материалы делятся по функциям на разные группы, эти группы на подгруппы, вложенность может быть до трех-четырех пунктов(Пример:Прозрачные материалы->Склеивающие материалы->Заливочные полимеры)
У этих материалов есть свойства(характеристики), эти свойства также делятся на типы (Пр: Технологические->Электрические)

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

Одной таблицей влоб перечислив все параметры не обойтись, да и нельзя так. Так что надо придумать оптимальную структуру базы в 4 нормальной форме, хотя нормализовать я сам смогу.

Прайс лист я привел в качестве примера, т.к. он очень похож на мою задачу да и для вас он ближе

N'drew в чём думаешь писать

Для начала хочу всё это набросать в виде пилотного проекта на Accesse, в конечном итоге нужно на дельфях интерфейс смастерить, а СУБД предположительно paradox, точно ещё не определился, где проще будет, может msSQL.

Неужели никто не может помочь?

tovar
------
(primary key)id,
naimenovanie,
opisanie

tovar_harakteristika
-----------------------
(primary key)id,
(foreign key)tovar_id,
naimenovanie_harakteristiki,
parametry_harakteristiki

history
-------
(primary key) id,
(foreign key) tovar_id,
price,
price_date

базу лучше на каком-нибудь SQL сервере - файрберд, МС, акцесс.

wCat
Да, проще не придумаешь...

дык
смотря шо/для чего/зачем

wCat ну это уж совсем просто. Я например подумал что для хистори можно ввести 2 ключа - tovar_id и дата, т.к. не так часто бедет цена меняться.
А вот как быть с типизацией товара.
К примеру, Моник-> Моник_LCD -> экран 17"
Куда эту типизацию примкнуть, чтобы легче было заполнять да и затем запросы делать на определенные типы товара.

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

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

N'drew
Ну так опиши подробней, чо надо...
Тогда, скорее всего, и помощь не понадобится...
Чтобы проблем не схватить - нормализацию надо делать... но тогда запросы сложнее будут.

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

wCat N'drew
Чисто прикидка... материнска плата:
Производитель (справочник производителей)
Сокет (справочник сокетов)
Чипсет (справочник чипсетов)
Поддерживаемые процессоры (справочник типов(!) процессоров, т.к. есть варианты... а ещё версия БИОС, ревизия... уууу!)
Видео (эээ... даже не знаю... интегрированное (справочник?) AGP 4Х, AGP 8Х... PCI-E, ...SLI?)
Сеть, USB, 1394... мрак!
...
Это, если нормализовывать, а не строку писать, как в той же Ультре и делается (из их XML-прайса на раз-два детальную инфу не вытащить)...
Короче: XML!

Так ну и я свои пять копее - рано помоему вы тут бросились код писать...
Значит помоему начать следует с построения логической ER модели:
1. Выделение основных сущностей;
2. Идентификация связей между сущностями;
3. Идентификация атрибутов сущностей.

Это как раз самое главное.


Пишу подробней.
Есть материалы для создания светотехнических изделий, эти материалы делятся по функциям на разные группы, эти группы на подгруппы, вложенность может быть до трех-четырех пунктов(Пример:Прозрачные материалы->Склеивающие материалы->Заливочные полимеры)
У этих материалов есть свойства(характеристики), эти свойства также делятся на типы (Пр: Технологические->Электрические)

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

Одной таблицей влоб перечислив все параметры не обойтись, да и нельзя так. Так что надо придумать оптимальную структуру базы в 4 нормальной форме, хотя нормализовать я сам смогу.
Можете посоветовать какая СУБД для дельфей будет оптимальней под эту задачу, но сначало надо все это набросать в акцессе, чтоб проверить функциональность.

Прайс лист я привел в качестве примера, т.к. он очень похож на мою задачу да и для вас он ближе

N'drew
Понятно... Ну так прикинь справочники (список производителей, параметров и т.д.) все (некие атомарные вещи), свяжи их - и будет тебе база... По и-нету сложно... Поверь, в реале за бутылкой пива за 10 мин. накидали бы... вопрос сильной нормализации - вопрос построения запросов после... Не всегда полезно... А твоя задача раскладывается в реляционную базу нормально...
Если не спешишь - можешь задачку (подробно!) сегодня(!) мне на мыло закинуть... На выходных гляну... Не вопрос!

InSite впринципе есть ещё 2 недели как минимум на это, если поможешь в чем нибудь то буду очень благодарен.
К сожаления я сейчас на работе, и у нас отключен почтовый протокол, поэтому отправлю тебе письмецо дома, часов в 5 вечера, ок?

А ведь ещё отчет по этой базе катать нужно на 40 страниц, практика как никак

N'drew
17:30 заканчиваю работу... дома и-нета нет.
Постарайся успеть.

хорошо ляжет на дерево:
TABLE groups (
ID INTEGER NOT NULL, - ПК
PARENTID INTEGER NOT NULL, - родитель, если 0 имеем верхний уровень
NAME D_NAME NOT NULL - название
CCOUNT INTEGER DEFAULT 0 - количество детей (необязательно, в принципе. шоб базу поменьше дергать. заполнять в триггере можно)
);
select * from groups where parentid = :id - отбираем детей

аналогично для типов свойств.
в товаре привязаться по ID групп.

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


многие вещи удобно выбирать в хранимых процедурах, которых нет в аксцессе

Всем привет.
Посмотрите пожалуйста схему БД, в ней есть 2 дерева, дерево типов и свойств материалов, есть сами материалы и производители с поставщиками.
Сможет ли работать база с такой схемой или чтото надо поменять?
#77

К сожалению InSite не смог мне помочь, т.к. он очень занят