30 символов в Оракле

Задумался: почему три самые страшные базы данных, которые я видел за свою карьеру, были сделаны именно на Оракле? Есть ли в самом Оракле какой-то принципиальный недостаток, который побуждает разработчик создавать монстр-спагетти с тысячами тесно связанных таблиц, представлений и хранимых процедур?

Пожалуй, главная проблема не техническая, а культурная.

25 лет назад работал себе программист с разрозненными базами FoxPro. И тут ему дали новую игрушку (а тогда Ораклу альтернатив фактически не было), которая позволяет собрать всё в одну кучу, и делать с этими данными, что угодно.

Но то, что ты можешь делать, что угодно, не значит, что должен делать, что угодно. Это как истощенного человека нашли на необитаемом острове и отправили в гостиницу "все включено". И вот годы идут, уже пузо висит, а он продолжает жрать и жрать: пихает всё, что есть, в одну базу и пишет километровые запросы.

И в принципе ж даже при такой database-centric архитектуре технически можно создавать более-менее нормальный код: ладно, пусть всё в одной базе, но хотя свести к минимум обмен данными между схемами; и делить представления, процедуры и пакеты на какие-то логические кусочки. Но постаревшие уже "обжоры" этого не делают... Только copy-paste, только хардкор...

А если говорит чисто о технической стороне, то в Оракле много мелочей меня бесят. Например, как получить только 10 первых записей? В MS SQL - добавить вначале TOP 10. В MySQL или Postgres - добавить в конце LIMIT 10 (мне кажется, это логичнее, но не суть важно). А как в Оракле?

FETCH NEXT 10 ROWS ONLY

У меня пальцы болят это каждый раз печатать. Почему нельзя просто FETCH 10? Или FETCH NEXT 10? Ну, хорошо, я понимаю - может, будут какие-то проблемы с совместимостью. Но зачем это ONLY, что оно символизирует? Может, дело в том, что вместо ONLY есть ещё какая-то другая опция? Но нет, это не так. А ещё вот этот вот ROWS. Причём для красоты разрешается и ROW. Но при этом можно писать грамматически некорретные запросы "1 ROWS" или "2 ROW", которые работают.

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