2Moderator: сорри за offtopic, но народ здесь опытный, интересно знать мнение...

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

С уважением, Андрей Митин
ICQ:38607432
http://am.rusimport.ru

>>вижу несколько путей: можно завести каждый типоразмер как отдельный товар (тогда при выписке накладных выбирается конкретный типоразмер, но проблема с ростом ассортимента и отчетами потоварно)
>Это будет ненормализованная таблица.
Чем это она будет ненормализованная?
Если каждый размер мы представляем отдельным товаром, н-р
Товар ID=1 Name="Краска 'Суперэкстра' красная" Цвет=Красный
Товар ID=2 Name="Краска 'Суперэкстра' зеленая" Цвет=Зеленый

>>Можно ввести доп. табл. типоразмеров, но тогда в документах необходимо указывать товар и типоразмер вместе...
>А если нам нужно будет узнать сколько товара определенного типаразмера есть в магазине, как будем это делать?
Обыкновенно - группируешь по товару - остатки товара, группируешь по товару,типоразмеру - остатки по типоразмерам...

(я не отстаиваю этот вариант как хороший, я просто пытаюсь для себя понять как корректно делать...)

Мне не очень хочется ввязываться в спор, но всё же...
>>Чем это она будет ненормализованная?
>В вашем случае поле "Цвет" зависит от поля "Name" - это 2-я нормальня форма, смысл нормализации в избавлении от повторяющихся групп, а у Вас данные поля Name повторяются. Обычно при проектировании БД стараются нормализовать хотя бы до 3-й нормальной формы.
Отношение (будем так называть таблицу) тогда удовлетворяет 2-ой нормальной форме когда каждый из его атрибутов, не входящий в состав PK полностью функционально зависит от всего PK а не от его части. В примере, который я привел нет составного ключа - есть PK ID, от которого функционально зависит атрибут Цвет, и есть AK (альтернативный (потенциальный) ключ) NAme - от которого тоже зависит атрибут Цвет. Так как оба детерминанта отношения являются его потенциальными (если точно - один суррогатный ключ, второй потенциальный ключ) ключами и в отношении нет транзитивных зависимостей, то теоретически данное отношение (с 3мя атрибутами ID,Name,Color) удовлетворяет даже НФБК.

>Туфли женские размер 37 количество 20
>Туфли женские размер 38 количество 30
>Фактически наименование товара можно представить как тип товара, который будет справочником наименований, а реальный товар будет представлен в другой таблице с атрибутами размера и количества в магазине со ссылкой на справочник.
Да, можно, только с учетом того, что товары могут быть и без типоразмеров (ну допустим кроме ботинок есть ещё ложечки для их одевания ), тогда в документах товародвижения должен присутствовать или код из Вашей второй табл. типоразмеров, либо код из основной табл. товаров. Усложняется поддержка ссылочной целостности (особенно если в СУБД нет триггеров).
(кстати никогда бы не стал держать количество в магазине в справочнике товаров(типоразмеров), думаю Вы привели этот пример просто очень сильно его упростив...)

>Это я весьма упрощенно рассмотрел только одну сущьность из Вашей задачи. Научить правильно проектировать БД в двух словах невозможно, если действительно хотите научиться правильно проектировать БД почитайте соответствующую литературу.
Спасибо, обязательно почитаю, кстати, не порекомендуете ли что-нибудь?

>Вот только неувязочка, как же Name может быть у Вас АК, если он не уникален?
как неуникален? конечно уникален я же специально и писал название в кавычках чтобы показать что они разные... То есть я хотел сказать что каждую модификацию (типоразмер) сущности "Товар" я буду считать сущностью "Товар".
Как то слишком академично получается... Если по простому - только что посмотрел Парус - у них это решено тем, что для любого товара есть модификации (т.е. две таблицы наверное, Товар-Модификации) и во всех товародвижениях участвует именно идентификатор модификации. Это достигается тем что для любого товара должна быть как минимум одна модификация, то есть для Товара "Ложечка" должна быть модификация "Ложечка"...

И всё же очень хотелось бы послушать остальных глубокоуважаемых специалистов-практиков...


>>Спасибо, обязательно почитаю, кстати, не порекомендуете ли что-нибудь?
>Стандартный ответ: Дейт "Введение в системы баз данных" (если не напутал в названии)
Спасибо, , я читал Томаса Конноли и ко... "Базы данных".

2 yzif & Павел:
Что необходимо запоминать в документах, чтобы узнать остатки на складе желтых летних мужских ботинок 41го размера?

2 Константин:
В общем то тот же вопрос, что предлагаешь запоминать в документах товародвижения - оба поля (первое Товар, второе Признак товара (и если признака нет то Null))?