> не уверен, что такое разделение объекта на 4 таблицы правильно

Исходную задачу полностью сформулируйте.

> Может стоит сделать для ОС специальное поле, в котором хранить ОС
> примерно так Win2k|Linux|...

Так точно делать не стоит. ;)

Вы же, member Dogen из Гондураса, вроде первоисточники конспектировать собирались? Уже надоело?

> Зато можно хранить в блобе XML, а в нем Win2k|Linux|...

Можно поинтересоваться, у какого автора Вы этого бреда начитались?

> В блобе действительно можно хранить XML

Можно, я не буду пробовать?

> В данной задаче это, конечно, не нужно

Я Вам больше скажу: не существует таких задач, где это было бы нужно.

> это намного лучше

Да нет, ничем не лучше. Точно так же криво. ;)

> надо создать таблицу наборов свойств объектов

Мы же вроде договорились, что термин "объект" уточняем до употребления? Нет в реляционных СУБД объектов. И быть не может.

> а затем

Знаете основной принцип хорошего проектирования? ;) Нужно сложное сделать простым. В данном случае это довольно легко. Давайте посмотрим, какие ошибки сделал автор и как их исправить. Поскольку автор молчит, предположим, что пишется некий каталог софта. Классифицировать ничего не будем.

Хотелось бы увидеть Ваш вариант описания ошибок.

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

Нет, автор об этом не писал, поэтому такой функционал не будем рассматривать.

> ОС - в отдельном классификаторе

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

> Страна с программой имхо не соотносится никак

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

> Со страной может быть связана цена на лицензии

Да, может.

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

Imho придется. К сожалению. ;)

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

Ошибки автора (те, что на поверхности; в предположении, что автор выступает как хм... некое промежуточное абстрактное звено между исполнителем и заказчиком и абсолютно нейтрален):

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

2. Недостаточно полно определено понятие "операционная система". Вариант дополнения: было бы правильным иметь возможность дополнительно указывать тип, версию (в т. ч. отдельно - версию компонентов (например, ядра или графической среды) семейства операционных систем), билд, сервис-пак и пр., - т. е. факторы, которые могут влиять на возможность компиляции и/или установки и/или запуска "программы". Необходимо иметь возможность указывать диапазон версий (билдов и пр.) ОС или только их типы или только версии компонентов.

3. Неправильный выбор "операционной системы" как единственного ограничивающего фактора. Необходимо иметь возможность указывать для "программы" не перечень или тип операционных систем, а среду выполнения (включая виртуальные машины, серверы приложений, наличие/отсутствие библиотек, компиляторов и пр.); понятно, что для среды выполнения типы, версии и пр. ботва - аналогично операционным системам.

4. Одна и та же программа может выпускаться под разными лицензиями (это Вы отметили); вид лицензии может зависеть от целевой операционной системы, количества пользователей, способа применения, технических параметров аппаратной конфигурации и пр. Возможно, доступность документации и/или поддержки связана с видом лицензии.

5. Ошибочна связь локали со страной, - это Вы тоже отметили.

На самом деле, конечно, можно придумать и другие зависимости (например, я бы обязательно описал разработчиков софта и пр.), но, поскольку автор о них ничего не сказал, мы тоже фантазировать не будем.

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

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

Т. о. я бы посоветовал автору варианты: написать нормальное техническое задание и нанять вменяемых исполнителей или не париться и реализовать все в одной таблице, - это лишь немногим более криво, чем в четырех. ;)

> Читать "ОС - в отдельном справочнике". Имелась в виду классификация программ.

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

> Я так понял, что имеется в виду программный продукт - коробка или набор файлов.

Правильно. Пожалуйста, найдите в Сети описание отличий пакетов, сформированных для разных операционных систем. Опционально - описание форматов пакетов. ;)

> Это все атрибуты продукта, но автору вполне может быть достаточно артикула по каталогу :)

Возможно. Фишка в том, что артикул - это и есть идентификатор владельца пакета с учетом перечисленных атрибутов. ;))

> Тогда уж лучше ввести справочник необходимых программ/библиотек... и т.д.

Да, лучше. Примерно представляете себе затраты на такой справочник? ;)

> Диапазон версий ОС думаю излишне

Нет. Например, для Linux версия операционной системы связана с версией ядра. ;)

> Все по тому же принципу - видишь сущность, ее и отражай. Без извращений.

Видите ли, "что вижу - о том пою" - это плохое правило по отношению к проектированию.

> я бы предложил какую-нибудь XML БД

Например? ;)

Дружище, Вы, к сожалению, не поняли основного: пофиг, какая реализация физически будет выбрана. Важно задать правильные вопросы и иметь на них правильные исчерпывающе полные ответы. ;)) Ключевые слова при этом - "возможность естественной идентификации". ;))

> Вы верите только всему что напечатано?

Дружище, Вы слышали, чтобы я когда-нибудь это говорил? ;)

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

> Практиковать попробуйте,

Что именно?

> сразу поймете что многие напечатанные вещи - бред,

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

> а многое из того, что казалось бредом прекрасно работает.

Кривое решение - оно и есть кривое решение, независимо от того, прекрасно оно работает или не очень.

> У Вас с классификацией те же семантические проблемы

У меня? ;)) Боюсь, что, как и в случае с информацией, это не у меня проблемы. ;))

> Это в данном случае не нужно

И все-таки найдите. ;) Надеюсь, необходимость будет более понятна.

> В данном случае под артикулом полезнее будет понимать
...
> Фигня вопрос.
...
> Например

;)) Как говорил один наш общий знакомый, я вежливо замолчу.

> какую указать версию для Fedora Core 4

О чем я и говорю: указываем либо версию операционной системы, либо версию ядра. ;) Написали FC4, - значит, для всех ядер, с которыми она выходила. ;))

> Предложите Ваше правило .

Уже. Снова что-то пропустили? ;)