mad_nazgul
Если хотите дорого и тяжело, то Java + Oracle


Думаю можно продолжить :-)
Можно уточнить: Не обязательно Java и поэтому не обязательно тяжело: от Oracle тежелого вроде ниче не придвидится. Наоборот, на всем ЖЦ скорей всего проще: полно фич у Оракла, чтобы разруливать по ходу траблы, которые не удалось предвидеть по тем или иным причинам. Не обязательно дорого: есть даже бесплатные редакции.

mad_nazgulJava - тяжело... ибо клиент на нем...

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

mad_nazgulOracle - это большой баян с кучей кнопок.
Не знаю что это означает, но подозреваю, что речь идет о каком-то неудачном студенческом опыте.
Однако, думаю, что СУБД Oracle - удачный выбор, в частности, потому что у него много фич (ручек), позволяющих часто по быстрому разруливать разные требования, появляющиеся у заказчика по ходу или там траблы не предвиденные разработчиками.
Конечно, есть много проггеров готовых дописывать недостающие ф-ии СУБД на клиенте, да и вообще изобретать велосипеды.
Но не у всех же стока рвения. Кому-то проще када СУБД предоставляет по макимому ф-ии по управлению данными. Таким луче кучу фич в СУБД.

mad_nazgulВот это и называется "баян с кучей кнопок", когда количество "фич" превышает все разумные пределы. :-)
Так тем кто назвал фичи мешают? Тут ждешь каждую новую версию в надежде на новые фичи, а им пределы превышены? Хороши. Ниче не скажешь. В 8 Оракле превышены? А мне теперь после 11 кажется, что на нем по нынешним временам принижены все разумные пределы. На нем снес по ошибке данные, а тем более таблу и привет, если нет Бэкапа. Апекса нет – это чтобы по быстрому налабать клиента. И т.д. т.п. А Вы говорите, что превышены пределы.
Када-то станки превышали пределы, лишая рабочих работы. Там всякие михайловцы или типа того боролись с ними. Ну теперь другие времена. Да и станки те кажутся допотопными.

mad_nazgulА кто говорит что плохи?
Просто их много. ;-)

А разве их много бывает?

mad_nazgulЧем больше фич, тем сложнее "инструмент". ;-)

Чем больше фич, тем проще с этим "инструменитом" "инструментировать". Например, снес по ошибке в командировке данные, а у вас есть фича простым запром вернуть обратно.



mad_nazgulА зачем бороться?
Сами "умрут". ;-)

Тем более.

mad_nazgulЕсли для нормальной работы нужны "фичи", то либо инструмент подобран не правильно, либо задача решается не правильно.
"Нормальной работы"? Правильно подобран? Ну так я и говорю что чем больше фич, тем правильнее. Ить фичи могут быть нужны чтобы снизить риски "не нормальной работы" разработчика на всех этапах ЖЦ системы. Любой проект, к, сожелению, имеет разного рода риски. Например, по ходу потребовал заказчик чтобы БД сама оповещала клиента о каких-то критических изменниях данных. Есть фича оповещать клиентов подписавшихся на рассылку событий даже када нет сессии. А нормальная правильная работа клиенту через кажную секунду спрашивать проверять не произошли ли такие изменения?

Если не обращать внимания на проггеров готовых дописывать заплатки вместо фич СУБД, то, скорей всего, "фичи" нужны для "нормального" ЖЦ ИС.

mad_nazgulБывает. :-)

Ну это возможно какое-то сильное предположение, нуждающееся в дополнитекльных подтверждениях.


mad_nazgul
Э-э-э вообще-то нормальный инструмент не дает "напортачить".
Если дает, то предполагается, что пользователь может сам "решить проблему".

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

mad_nazgulИ вообще "универсал, это тот кто делает все одинаково плохо" :-)
Поэтому я очень "настороженно" отношусь к добавлению фич.
Если фича нужна, то это скорее всего проблема в проектировании, либо в инструменте.


Понятие унивенрсал нуждается в некоторм уточнении. Однако, мы же видим, что если есть фича секционирования у СУБД, это не делает ее хуже тех СУБД у которых таковой нет, скорей всего. Т.е. добавление данной фичи, некоторые тут вроде даже приписывали своим СУБД, хотя их в последствии там не оказалось. Это делает, возможно, Вашу теорему о вредности фич по факту самого своего существования преждевременной. Более того, возможно, Вам следовало бы относиться с "настороженностью" к отсутсвию таковых.

У Оракла, по крайней мере, проблем в инструменте по сравнению с другими СУБД вроде особо не обнаруживается.
А проблемы в проектировании могут оказаться у любого. Такие риски исключать было бы чрезмерно самонадеяно. А ЖЦ в общем случае может иметь модели не предполагающие на этапе выбора СУБД предвить все.



mad_nazgul
Опять же проблема при проектировании.
Зачем в СУБД пихать мессенджер?!



А что его с наружи пристраивать? Событие то в БД произошло. А допустим моного событий. А допустим много разных клиентов должны получать сообщения разной природы. Ну есть проблема, если нет фичи. Бомбят клиенты БД запросами. А событие мож раз в год произойдет, а то и никада.

mad_nazgul
Зачем?!
Зачем иметь в СУБД мессенджер, когда можно использовать любой внешний?!
Может СУБД еще должна уметь проигрывать AVI файлы?
Тоже фича. Возможно даже кому-то нужная.

Это какой внешний? Как он узнает, что в ней что-то произошло? Запрос пошлет? Кажную секунду? Написаный проггерами или мессажер ОСи приспособить? Так оси разные могут быть. И прог много может быть.
Если СУБД файл-серверная, то типа и проигрывает. А клиентсевреная может тока запросы возвращать, которые юзеру клиент представляет. В том числе и фильмы. А так да у Оракла есть поддержка и мультимедиа.