Oracle - одна из богатейших софтверных фирм. Тем не менее, не может сделать себе инструментарий хотя бы в первом приближении уровня Microsoft-а, известного своим внимательным отношением к разработчикам - самому главному фактору для продвижения платформ и решений. И не думает лечить "детские болезни" 20-летней давности.

Текст ниже содержит технические страшилки.

Начнем с TOAD. Ясно, что хорошее дело жабой не назовут. Несмотря на обильную функциональность этот инструмент представляет собой пример того, как НЕ надо проектировать пользовательский интерфейс. Десятки мелких кнопок и закладок в несколько рядов не способствуют, мягко говоря, эргономике. Microsoft SQL Server Management Studio не говоря уже о Visual Studio Data Tools - это какие-то космические технологии. По сравнению. Тем не менее, TOAD по умолчанию стоял у всех (!) виденных мной команд разработчиков, связанных с ораклом, иллюстрируя извечное "мыши плакали, но жрали кактус". С юникодом у него беда, но это видимо, из-за того, что разработчики "жабы" так и не перешли на Delphi старших версий (продукт написан на Delphi).

Теперь сам движок БД.

Схемы по-прежнему привязаны к пользователю. Никаких пространств имен. Пользуйтесь префиксами и не балуйте.

Все еще живо ограничение на длину системных имен в 30 символов в 2012 году... Спасибо, что не "8.3".

Наличие фактически единственного типа NUMERIC с переменной размерностью пахнет тяжелыми и так и не вылеченными болезнями детства, уже очень далекого.

Например, тип int в SQL Server занимает 4 байта. В оракле требуется выделить NUMERIC(10), что займет, согласно документации, 6 байт. Вроде бы небольшое отличие, но на таблице со 100М записей разница по хранению без учета компрессии получится 200 МБайт помноженной на число целочисленных колонок, как правило, внешних ключей. Аналогично с типами tinyint и smallint.

Отсутствует логический тип. Но беда не в самом отсутствии, а в том, что лучшая практика - использование типа VARCHAR2(1) с ограничением типа CHECK column IN ('F', 'T'). Для сравнения, в SQL Server используется тип bit, занимающий один бит, выровненный до 1 байта. То есть от 1 до 8 логических полей займут 1 байт при хранении.

Опять же, лучшие практики советуют, но не объясняют, почему тип VARCHAR2(n) эффективнее CHAR(n) если длина значения фиксирована. Ведь для полей переменной длины где-то должен храниться байт-терминатор или длина. Спецификация на физическое хранение не прояснила этот вопрос.

Напоследок маленький пример, без сомнения стимулирующий разрабатывать ваши программы под Оракл.

Простейшая конструкция

CREATE TABLE T1 (
  ID_T1 NUMBER(10) NOT NULL ,
  CREATED TIMESTAMP NOT NULL DEFAULT SYSDATE
)

Выдаёт ошибку для 10g:

Error at line 1
ORA-00907: missing right parenthesis

В чем проблема? А просто в том, что надо поменять местами объявления DEFAULT и NOT NULL. Вот так

CREATE TABLE T1 (
  ID_T1 NUMBER(10) NOT NULL ,
  CREATED TIMESTAMP DEFAULT SYSDATE NOT NULL
)

Table created

В общем, исторически не сложилось как-то у разработчиков с формальными грамматиками...