guest_20040621> Боюсь, что даже в определенном контексте не всех устроит предложенная кем-л. классификация.

Вы не поняли. Контекст - это не то, чего хочет левая нога, а вполне себе конкретный способ реализации структуры данных. Наиболее близкая аналогия - namespace.Теперь я уже не понял. При чем тут способ реализации структуры данных? Мы же не подразумеваем проектирование в отрыве от типов данных СУБД (ну хотя бы в сравнительно идеальном варианте).

guest_20040621> не может ВСЕХ устроить субъективный выбор

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

guest_20040621> кстати, так оно часто и бывает

Да. И это плохо.А не с теми совещаются. Сюда надо, сюда

guest_20040621
Боюсь, все не так просто. Самый простой пример: товары и услуги. Их легко классифицировать и по ОКВЭД, и по ОКПО. Оба классификатора достаточно подробны. Но для практического применения оба крайне не удобны (за пределами, разумеется ВЭД и статистического анализа соответственно).
Весь базар ведь и идет о практически применимом классификаторе? Я к тому, что автору вместо обкладывания себя на километр в каждую сторону соломой - где бы не упасть - стоит прорисовать ER-диаграмму того, с чем собирается работать, и поразмышлять над алгоритмами обработки данных в конкретной системе, глядишь, и понятно станет, какие сущности и атрибуты оставлять.

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

А коды ОКВЭД и ОКПО нужны для печати в документах :)

guest_20040621

> понятно станет, какие сущности и атрибуты оставлять

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

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

guest_20040621> прилично спроектированная структура данных расширяется без особого геморроя

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

КДЯ недостаточно подробно обрисовал задачу?

Задачу описали - вполне подробно.

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

Далее обсуждались возможности по упрощению универсального решения задачи о построении классификатора товаров.

И говорилось о том, что для рационального построения этого самого классификатора надо подробнее описать предметную область, бизнес-процесс и тому подобное.

Is it clear?

Вернемся к конструктиву.

КД Я только спросил, с чем связывать показатели товаров (реактивов) – с товарами или с наборами.С товарами связывать "объект типа Показатель товара", минимальный набор объектов-Показателей задается объединением всех категорий товара.

КДв дискуссии о построении универсального классификатора товаров я участия не принимал, разве что заметил, что это в принципе невозможновозможно, в том числе и без АБД (но по ходу наполнения БД данными придется описывать вновь появляющиеся типы показателей)