структура базы, которая хранит разные прайсы

[spiner]

структура базы, которая хранит разные прайсы

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

 

[alexhemp]

Одна таблица - список фирм.

Другая таблица - список товарных позиций. Каждая позиция ссылается на одну из записей списка фирм.

Если нужна история - добавляем 3-ю таблицу.

 

[Alexandre]

и еще таблицы:
property - специфические поля для прайса
price_property - данные специфических полей для прайса

отношение:
price -< property -< price_property

 

[spiner]

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

Alexandre

property - специфические поля для прайса

т.к. я не понял, где хотел хранить шапки
alexhemp, то у меня вытекает вопрос: а неспецифические поля для прайса где бы ты хранил?

Спасибо!

 

[alexhemp]

spiner

Я вашей терминологии не понимаю, что есть "неспецифические поля прайса".

Насколько я понимаю, сам по себе прайс не существует, а он есть пересечение трех сущностей

1. Фирмы и связанных с ней атрибутов (адрес-телефон и т.п.)
2. Даты формирования и других общих атрибутов (курс у.е.)
3. Товарных позиций (бренд-название, Part Number)

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

Таким образом у нас получается минимум 3 таблицы

1. Фирмы (Название, Адрес, Телефон)
2. Прайс (Фирма, Дата формирования, курс)
3. Строки прайса (Ссылка на прайс, Товар, Цена)

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

 

[spiner]

alexhemp
вообщем ушли от самой задачи.. поясню. Допустим есть фирма Ж. Фирма Ж имеет шапку прайса вида:
Наименование | Цена | Проникаемости % | Влагостойкость % | Размер | Производитель

Далее есть фирма Х. У нее шапка прайса вот такая:
Наменование | Цена | Цвет | Ударостойкость % |

Так наверное проще будет? Нет?

Я думаю сделать так:

Таблица фирм:
ID_corp | Name | ID_shapki |

Таблица товаров и в ней же и хранить шапки:

ID_record | ID_corp | Name_tovara | Pole1 | Pole2 | Pole3| Pole4 | ... | Pole_n | Type |

В поле Type писать tovar, если это товар, и писать shapka если это шапка..
И когда нужно выбрать например прайс фирмы Ж, найти в таблице товаров найти запись с ID_corp и type=shapka, вот и вывелась шапка, а потом другим запросом выводить уже type=tovar..

По-моему так.. Просто к сожалению я сейчас попробовать не могу..
Нормальная идея?

 

[alexhemp]

Это нужно было объяснить с самого начала.

Ценность хранения таких прайсов от меня ускользает (нет унификации данных), тем не менее делается по уму это не так

1. Таблица фирм (Название, Адрес)
2. Таблица атрибутов (Название)
3. Таблица прайсов (Фирма, Дата)
4. Таблица товаров (Бренд, Наименование, Код)
5. Таблица значений (Прайс, Товар, Атрибут, Значение).

НИКОГДА не меняй из программы МЕТАДАННЫЕ - т.е. СТРУКТУРУ таблиц.

В твоем случае нужно под каждый тип прайса делать новую таблицу

В моем можно еще много чего совершенствовать, без особых изменений базовой структуры.

Например можно ввести "тип" прайса в виде шаблона набора атрибутов - например для упрощения ввода.

-~{}~ 18.03.06 15:12:

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

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

 

[spiner]

Да и еще подумайте - не являются ли все поля кроме цены - характеристикой товара а не прайса.

являются конечно, НО информация на входе (т.е. которая приходит непосредственно от фирм) выглядит так :

Наименование | Цена | Проникаемости % | Влагостойкость % | Размер | Производитель

Менять ее самому - это очень долго.

Вообщем я почти понял. Спасибо.

 

[baev]

Менять ее самому - это очень долго.

— не понял. Что менять долго? Структуру таблицы?

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

 

[spiner]

baev
Долго менять прайс фирмы. Например, поля которые являются характеристикой товара, пихать в наименование товара.

 

[alexhemp]

Если Вы и сами знаете что вам долго, зачем тогда спрашиваете?

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

Вы с этими прайсами потом что делать будете?

 

[spiner]

Вам нужно построить модель предметной области

согласен
С этими - это с какими? Которые в базе или которые в xls? Не понял вопроса.

 

[alexhemp]

Вы определитесь что вам реально нужно

1. Просто хранить присланные прайсы - тогда база вам не нужна, записывайте в исходном виде и все

2. Хранить данные в базе, делать к ним сложные запросы.

Если второе - нужна УНИФИКАЦИЯ данных, т.е. четкая модель предметной области.

У вас же - нет никакой унификации. Я вам предложил как ее сделать - для этого нужно отказаться от хранения прайса точно в таком виде как он пришел (для этого достаточно сохранить исходный файл, что само по себе идея неплохая).

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

Цвет и другие характеристики - свойства конкретного товара.
А вот условия поставки могут быть свойством прайса.

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

 

[spiner]

alexhemp
спасибо

 

[donhenarophp]

Лучше всего организовать 2 основные таблицы - одна - список фирм. Другая - список товарных позиций. И пусть первая берет записи со второй.

 

[alexhemp]

donhenarophp

Человечище! Топик прочитай, а потом давай "умный" комментарий. Автор и сам понимает что таблица будет не одна, хочет тонкости выяснить.