Абсолютный бред. Вам в детстве не говорили, что не стоит читать то, что пишут на заборах?

> когда проектирование ведут в PD - всегда дерьмо получается

Других инструментов для проектирования, кроме убожества от Сайбес, уважаемый дон не знает?

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

> В ITSM-системах, а речь идет именно о них, базы данных обычно простые.

Это говорит только о том, что ни Вы, ни автор этого бреда к проектированию баз данных никакого отношения не имеете. И об ITIL вообще ничего не знаете. Ну то есть абсолютно ничего. Ноль.

Одно непонятно: что заставляет писать ахинею?

> Если нечего сказать по существу

Саша, мне всегда есть что сказать по существу. В противном случае я не участвую в дискуссии.

> обливанию всего и всех грязью

Еще даже и не начинал. Вот если бы я написал "как задолбали ламеры", - тогда да, упрек был бы справедливым. А до сих пор я терпеливо объяснял, что

ITIL describes the processes needed to manage the IT infrastructure efficiently and effectively in order to guarantee the service levels agreed upon by the IT organization and its customers.

Service Support
- Configuration Management
- Service Desk
- Incident Management
- Problem Management
- Change Management
- Release Management

Service Delivery
- Availability Management
- Capacity Management
- IT Services continuity Management
- Financial Management of IT Services
- Service Level Management

Security Management

Application Management
- Software Lifecycle Support
- Testing of IT Services

Infrastructure Management
- Network Service Management
- Operations Management
- Management of Local Processors
- Computer installation and Acceptance
- Systems Management

Business Perspective
- Business Continuity Management
- Partnerships and Outsourcing
- Surviving Change and Transformation of business practices through radical change
- Understanding and Improving

Planning to Implement Service Management

Из чего абсолютно естественно следует, что базы данных для ITSM (IT Service Management) простыми быть не могут по определению.

Я ничем не могу помочь тем, кто этого не понимает. Ни сотрудникам РДТЕХ, ни модераторам, ни всем остальным.

Ага, кажется, я понял, в чем дело: не понравилось, что я назвал PD убожеством? ;) Все абсолютно честно: плююсь и ругаюсь матом, когда приходится им пользоваться.

> А чего тогда пользуетесь PD?

А чем еще пользоваться, если заказчик изначально нафигачил что-то в PD и ничем больше пользоваться не умеет? Переубеждать - смысла нет, эта работа не оплачивается.

> что можно было бы использовать вместо PD?

Задачи опишите.

> Без дискуссии на эту тему

Это как "без дискуссии"? Директивно: "вместо PD использовать %имярек"? ;) Разные у всех задачи. Кого-то и M$ Visio устраивает, а кому-то и MD UML не хватает.

> говорили все-таки об инструменте описания структур БД, а не бизнес-процессов

При чем здесь бизнес-процессы? Вы написали первое слово, ассоциирующееся у Вас с UML? ;)))

> негативно отношусь к высказываниям

Здесь и более странные люди бывают. Не удивили.

> что программеру по-фигу для какой БД писать

Э, нет. Совсем не все равно. Просто почитайте SQL-2003 и сравните, что и какие СУБД из этого стандарта поддерживают. Прибавьте к этому собственные фичи СУБД.

> и структура БД-вопрос вторичный, и главное, что есть сервер приложений

Не стоит ставить все с ног на голову. Какая модель приложения построена и что с ней можно делать - другой вопрос. Лично мне рисовалка ER-модели - а PD ни для чего больше использовать нельзя - как бы не очень нужна.

> На мой взгляд, можно выбирать только между PD и Erwin

Выбирайте. Не возражаю.

> А структуры БД нужно описывать обязательно. В скриптах для себя, на бумаге для Заказчика

Мартышкин труд - отдельно что-то описывать. Нормальный моделер позволяет строить нужные отчеты.