Возможно, вопрос поставлен слишком жестко, но все же.

Я думаю, многие меня поддержат. Реляционные базы данных — это большой геморрой. Возможно, ничего лучшего не придумано (?), но геморроем они от этого быть не перестают.

Два раза мне приходилось работать над проектами (и оба раза — неудачными ), где велась работа с разнообразными, но _родственными_ объектами. Или объектами, различающимися в одном свойстве, но от этого свойства изменялась логика работы приложения.

Пример
Имеем туристическую компанию, резервирующую места в отелях. Казалось бы, что может быть проще?

Резервации могут быть поименно/пономерно. Могут быть списком в n человек на заранее зарегистрированные номера. могут быть блоком (20 SNGL, 10 DBL, 5 TRPL) комнат на будущее.
Могут быть с полным питанием (Full Board, BB), могут быть с половинным (HB).
Могут быть с детьми (у разных отелей — разная политика на детей, например 0-6 бесплатно, 6-12 50% скидка или 0-4 бесплатно, 4-8 50%, 8-12 25%)
Могут попадать на межсезонье в отеле (половина — по одной цене, вторая половина — по другой, завышенной, а что делать — например Формула 1 проходит)

Представляете, да? При этом оператор должен видеть все эти резервации в списке, делать по ним выборку произвольным образом (а покажите-ка мне блочные резервации в отель Zurich с 15-го сентября сего года).

Что самое интересное, в таком случае проблема не в обработке данных — что их там обрабатывать? Проблема — в самих данных. Что как и куда хранить? Проектировка базы — кошмар. Нормализация базы — еще тот геморрой. Расширение понятия "резервация"? Практически нереально (дополнительные таблицы, колонки, ключи...) Я конечно не спорю, многое зависит от кривых шаловливых ручек разработчика, но, имхо, рано или поздно приходишь к выводу, что пытаешься "впихнуть невпихуемое".

Может, ну ее, эту реляцию, к чертям? Ы?