softwarer СерегаЯ имел в виду геморой другого рода. Когда например некий "товар" становится "группой". Типа была "Просто Обувь", а после захотелось сделать "Детскую", "Женскую" и т.д.
Товар - не может стать группой , если говорить о нашей реальности. Товар - это объект учета; пришло сто двадцать пар ботинок детских, артикул такой-то, код товара такой-то, код партии такой-то, прочее такое-то так-то. Группа - это некое виртуальное понятие, абстракция, придуманное для облегчения работы мозга.


Denis A. Группа это не товар и не может никогда мутировать в него .

Так оба правы или - нет? Мне представляется , что товар может стать группой , а группа товаром - нет.

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

Но , если принять такой подход, то почему же значение экземпляра(товара) не может стать типом(группой, только вот группой чего - группой новых свойств, или сложным типом, содержащим свойства) ?
Довольно не редко товары приходящие на предприятие так или иначе отражают в своих наименованиях-значениях их типизацию, например, была мука пшеничная,мука пшеничная 1сорт (... 2сорт)
мука ржаная,мука ржаная 1сорт (... 2сорт)
Более того у управленцев порой возникают желания у уже имеющихся в СУБД значений товаров выделить некоторые их свойства и вести их учет, например, у каждой из мук учитывать их влажность, уд вес, дисперсность, и т.д.

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

Описание типов модели
===================

Types - описывает все типы всех данных модели (ну или можно только подсистему какую-нибудь выделить)
------------ PK - Id
Id - это же и FK для TParents.Id и FK для TProps.Id
Name - имя типа
Domain - имя таблицы-домена значений типа(см условные имена "Domain1",...) для простых типов или Null для сложных
UniqValues - True, если Домен содержит уникальные значения,False - иначе. Необходим для контроля доменов, например , данных текстового типа.

TParents - описание родителей типов (родителей много м.б.)
-------------- PK (Id,IdType)
Id
IdType - FK для Types.Id или Null для не имеющих родителя (или вообще можно для безродных обойтись без записей в этой таблице)


TProps - свойства типов имеющих Id в таблице Types
----------- PK (Id,IdType)
Id
IdType - FK для Types.Id или Null для не имеющих свойств (или вообще можно для простых обойтись без записей в этой таблице)

Доступ к экземплярам данных
=======================

Objects - ссылки на все экземпляры всех данных модели
------------- PK - Id
Id - он же FK для OParents.Id и FK для OProps.Id
IdType - FK для Types.Id
IdValue - FK для Id таблицы домена для данного типа(см. имя в [Types.Domain]). Т.е. содержит ссылку на значение для простого типа, а в случае, если в таблице - домене IdType Not Is Null(значение стало сложным типом), то Ссылка на значения сложного типа (модифицированного в него простого) определяется Objects.Id.

OParents - Ссылки на экземпляры типов родительской части
--------------- PK (Id,IdObject )
Id
IdObject - FK для Objects.Id или Null для не имеющих родителя (или вообще можно для безродных обойтись без записей в этой таблице)


OProps - Ссылки на экземпляры типов собственных свойств
------------ PK (Id,IdObject )
Id
IdObject- FK для Objects.Id или Null для не имеющих свойств (или вообще можно для простых обойтись без записей в этой таблице)

Хранение данных модели ( для каждого простого типа модели своя таблица )
=================== ( в соответствии с Types.Domain)

Domain1 - набор значений типа имеющего имя "Domain1" (см. Types.Domain)
----------- PK - Id
Id
Value - Значение экземпляра ( само оно некоего абстрактного типа из набора типов данных СУБД )
IdType - FK для Types.Id или Null. Сложный тип в который модифицирован прежде простой тип Objects.Type или Null, если это простой тип (модификации не было) . Если Not Is Null, то значение экземпляра при поиске из Objects ищется по Objects.Id, являющимся FK для OParents.Id и FK для OProps.Id, которые в свою очередь и определяют значения экземпляра по цепочке. Т.о. , вообще говоря, любое простое значение экземпляра может превратиться в сложный тип, причем, Домен, становится скопищем значений и типов разных классов(тип и класс - суть одно), но сложные типы всегда можно развернуть до простых типов.

Domain2
-----------
Id
Value
IdType

.....

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