> Структура (читай, структура справочника) лекарственных препаратов
> по льготному обеспечению с момента выхода в начале 2005 года менялась 5 !!!! раз.

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

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

> специально для голубоглазых брюнетов (вводится два параметра: цвет глаз и цвет волос)

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

Извините, AlexTheRaven, дискуссии с дилетантами, как я уже говорил, мне не интересны.

> вы просто не можете

Отнюдь. Я просто не хочу. Я не хочу рассказывать, почему именно FreeBSD - это не энтерпрайз операционная система. Я не хочу тыкать Вас носом в HCL FreeBSD и списки рекомендованных ОС на сайтах SUN, IBM, HP, SM, Fujitsu, Dell и прочая, прочая, прочая. Не хочу. Потому как считаю это бессмысленным занятием. Точно так же и сейчас: я не хочу убеждать Вас в том, что Вы несете полную чушь, - потому как это тоже бессмысленное, долгое и не интересное занятие. Извините.

Вы, PL99, узковато понимаете глобальные задачи проектирования. Какой функционал должен обязательно быть заложен в любую проектируемую базу данных? Возможность ее эволюционного развития, возможность агрегации данных нескольких экземпляров базы данных, возможность ее интеграции в комплексные информационные системы. Для случая проектирования баз данных официального применения (здесь говорили о социальном страховании), последний пункт принимает стратегически важное значение. В первую очередь поэтому ни о каких извратах в виде не реляционных структур разработчику даже думать категорически нельзя. Если бы эти простые принципы соблюдались, и если бы информационными технологиями в стране рулили не полные бараны, давно была бы возможность построить комплексную информационную систему любого уровня, и проблемы, которые пришлось бы при этом решать, носили бы исключительно технический характер. Пока, к сожалению, я вынужден читать об элементарных ошибках тех, кто пытается проектировать такие базы данных. Конечно, я понимаю, что 90% наиболее квалифицированных разработчиков, говорящих на русском языке, проживают за пределами РФ, я понимаю, что проектированию баз данных, в общем, нигде и не учат, - но есть куча источников, которыми можно руководствоваться при решении любых проблем проектирования.

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

AlexTheRaven, Вы не поняли. Не "реализован", а "заложен". Другими словами, архитектор базы данных должен рассуждать примерно так: если мне понадобится вести историю изменений, я сделаю это посредством [...] без глобальных изменений структуры данных; если мне потребуется выделить несколько экземпляров базы данных для разных подразделений/задач, я сделаю это посредством [...] и агрегировать данные буду [...]. Если мне потребуется мультиязычный интерфейс, я сделаю это посредством [...]. И так далее, с учетом всех типовых задач. Практический результат такого подхода выражается в осмысленной декомпозиции структуры данных. Никаких "ФИО, дата рождения, номер паспорта" не получится по определению.

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