Подскажите какую структуру лучше выбрать?

[RigVan]

Подскажите какую структуру лучше выбрать?

Здравствуйте, подскажите какую структуру таблиц лучше выбрать?
нужно как-то объеденить в MySQL, следующие данные:

1) продукция (примерно 1000 наименований, и кол-во будет расти. Названия везде уникальные, поэтому можно использовать как ID)

2) вся продукция поступает от четырех поставщиков, кол-во вряд ли будет меняться (выборка по поставщикам производиться редко но все-таки бывает, чаще просматривается статистика по всей продукции)

3) по каждому товару есть четыре критерия:
..а) продано шт.
..б) кол-во заказов
..в) сколько раз смотрели описание
..г) средняя цена продажи

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

Какую структуру БД, для этого придумать, ума не приложу... Поскольку требуется что бы выборка могла производиться по любому(любым) из эти критериев...

 

[kewluser]

Прочитать любую книжку про теории БД, по нормализации БД.

Вообще, с первого взгляда задача довольно типичная, и много раз разными людьми решенная.

В кратце суть такая, каждой сущности должна соответстовать отдельная таблица.

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

Поставщиков тоже в отдельную таблицу - Поставщики, или контрагенты, как больше нравится.

Чтобы проектировать дальше, надо точнее понимать бизнес-процессы, которые вы пытаетесь описать.

Предположу что с "Продукцией" товаром, возможны две операции
- продать
- купить
У этих операций будет некоторый набор атрибутов:
- дата операции
- цена купли/продажи
- поставщик/клиент (обобщено контрагент)
- количество
- ...

В самом первом приближении это будет сущность "Операции", таблица, в котой будет находится информация, о действия совершенных с товаром, ну и соответственно поля примерно такие:
- ID товара
- ID контрагента (поставщик/клиент)
- тип операции (приход/расход)
- дата операции
- количество
- цена
- сумма

ну итд

 

[RigVan]

Прошу прощение за собственное делитантство.... я понимаю, что Вы пытаетесь объяснить что-то умное, но только мне к сожалению не понятное
Воможно я не слишком внятно объяснил суть собственного вопроса.
Дело в том, что никакие бизнес-процессы, как Вы выразились, мне
описывать не надо. Просто каждый день из сторонней програмы,
сливаются те данные, что я описал. Структура примерно такая:

продукция |поставщик | продано шт | кол-во заказов | просмотров |цена

Вот эти то каждодневные таблицы мне и надо как-то структурировать в рамках MySQL...

-~{}~ 27.02.06 21:28:

Соответственно должен быть еще такой критерий как дата

 

[kewluser]

То есть на самом деле вопрос в импорте данных, которые поступают к тебе в каком то заранее оговоренном в формате в MySQL БД?

1. Собственно в каком формате приходят данные? Это может быть например просто текст с разделителями, или что это?
2. В примере, котором ты описал никакая "дата" вообще не фигурирует.

 

[RigVan]

kewluser
да нет как раз с импортом проблем нет. проблема в моей голове, не могу придумать как эти данные скомпановать. Т.е. какие таблицы с какими полями лучше связатьь, чтобы работать со всем этим.... Короче говоря что в какую таблицу вложить, и как между собой все объеденить? Чистая теория, ни чего больше.

Re: 2. В примере, котором ты описал никакая "дата" вообще не фигурирует.

Как не существует? я же написал что все эти данные разносятся по дням... Т.е. в конце каждого дня мне дают ити таблички, (структуру которых я описал) Их то мне и нужно аккомулировать...