Конечно для случаев NVL(Field, DefaultValue) или NVL2(Field, NotNullDefaultValue, NullDefaultValue) это ничего не даст, но если для расчета значения по умолчанию используется функция (и еще через одно место написанная), то могут быть варианты.

В Oracle “умными” оказались только DECODE, CASE и COALESCE.

Отключить навсегда:

ALTER SYSTEM SET "recyclebin"=OFF SCOPE = BOTH;

Почистить для всех схем:

PURGE dba_recyclebin;

Зачем эта возможность добавлена, я так и не понял.

Deferrable constraints нигде нет. Да и не пользовали никогда. Вообщем – случилось и случилось.

Пришлось написать скрипт который ловит такие записи. Что с ними делать потом решать Вам. Все результаты сохраняются в таблице Exceptions.

DECLARE
 
  QuantityTemp NUMBER(23);
 
BEGIN
   BEGIN 
        EXECUTE IMMEDIATE 'DROP TABLE  EXCEPTIONS CASCADE CONSTRAINTS';
   EXCEPTION
        WHEN OTHERS THEN
          NULL;
   END;  
 
   BEGIN 
        EXECUTE IMMEDIATE 'create table exceptions(row_id rowid, owner varchar2(30), table_name varchar2(30),  constraint varchar2(30))';
   EXCEPTION
        WHEN OTHERS THEN
          NULL;
   END;  
 
   FOR X IN 
   (
      SELECT Constraint_name, TABLE_NAME FROM user_constraints
   )
   LOOP
      EXECUTE IMMEDIATE 'DELETE FROM Exceptions';
      BEGIN
        EXECUTE IMMEDIATE 'ALTER TABLE ' || x.TABLE_NAME ||  ' MODIFY CONSTRAINT ' || x.Constraint_name || ' VALIDATE EXCEPTIONS INTO EXCEPTIONS ';
      EXCEPTION
         WHEN OTHERS THEN
            NULL;
      END;  
 
      EXECUTE IMMEDIATE 'SELECT Count(*)  FROM Exceptions ' INTO quantityTemp;
      IF QuantityTemp <> 0 THEN
         dbms_output.put_line('Table ' || x.TABLE_NAME || ' CONSTRAINT: ' || x.Constraint_name || ' HAVE ' || QuantityTemp || ' problems. ');
      END IF;   
 
   END LOOP;
END;

Вероятно Вам приходилось обфусцировать plsql пакеты Oracle. Вероятно также что однажды утилита wrap не смогла это сделать. И Вы получили примерно такую ошибку:

kgefec: fatal error 0
kgepop: no error frame to pop to for error 603

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

Вы разбивали пакет на несколько пакетов, включали опцию /3Gb, обфусцирование делали где памяти немерянно, и т.д.

Всё это делали и мы, пока не оказалось, что вначале достаточно убрать лидирущие пробелы в коде (не руками конечно) перед обсуцированием.

Оказалось размер текста (не кода) критичен для обфускации и простым удалением лидирующих пробелов можно уменьшить текст процентов на 10-15%

И о чудо, гигабайта RAM достаточно для обфускации пакета размером в мегабайт. (Почему при этом используется 2.5GB RAM для меня загадка)

К счастью wrap в десятке делает все по уму, быстро и без излишнего использования памяти

Oracle 9.

Select Level from dual connect by Level < 200

Вернет строго 100 записей.

Select Max(Level) from dual connect by Level < 200

Вернет 199.

Приятно.

Но это еще не всё. :)

Select Max(LevelNo)
from
(
Select Level as LevelNo from dual connect by Level < 200
)

Тоже вернет 199

На Oracle 10 всё в порядке.

create view TestView as
Select Level as N from dual connect by Level < 10

Три следующих запроса работают нормально:

Select * from TestView;
Select N from TestView;
Select n from TestView;
Select "N" from TestView;

Не понравилось нам название колонки – N, меняем вьюшку

create or replace view TestView as
Select Level as "Test_Column"
from dual connect by Level < 10

Первые три запросы вернут ошибку ORA-00904. Последний четвертый выполнится без проблем.

Select Test_Column from TestView
Select test_column from TestView
Select "test_column" from TestView
Select "Test_Column" from TestView

Поначалу я решил что всё что заключено в двойные кавычки будет case-sensitive и надо обрамлять имя колонки в двойные кавычки и писать имя букву в букву с учётом регистра. Следующий пример это опровергает. Никаких проблем нет.

create or replace view TestView as
Select Level as "N"
from dual connect by Level < 10

Select * from TestView;
Select N from TestView;
Select n from TestView;
Select "N" from TestView;

Оказалось всё гораздно проще.

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

Если в запросе вы обрамляете название поле двойными кавычками, то его надо писать в верхнем регистре, если конечно в определении view вы не использовали двойные кавычки.

Ну где у Оракла логика?!

% — всё что угодно

_ — один символ

Я всё время считал, что escape character в Oracle это тот же процент (%). До тех пор пока не пришлось искать в строках этот процент и подчеркивание. После первого же запроса понял, что одновременно интерпретировать один символ как «всё что угодно» и escape symbol как-то несподручно.

select * from something where like field like ‘%%%%’;

Бесмысленный запрос получается, с escape — тем более :)

select * from something where like field like ‘%%%%’ escape ‘%’;

Это эквивалент field = ‘%%’

Но вот не пойму, им что, было сложно сделать back-slash escape символом :(, что бы не писать каждый раз escape ‘\’

Dotnet framework 2.0.

OleDbDataReader.

Первые сто строк вычитываются нормально, потом все идет крокозяблами. Думал поседею.

Четыре разных сервера, три девятки, одна десятка, проявляется только на одном.

Проблемы оказалась в параметре FetchSize (сколько строк возращать за одну вычитку), первый раз все вычитается правильно, все последующие вернут мусор.

Пришлось ставить FetchSize = 100000

Нашел описание проблемы здесь. А вот решения кроме вышепредложенного пока нет.

NVL(NVL(NVL(ColumnA, ColumnB) , ColumnC), ColumnD)

можно написать:

COALESCE(ColumnA, ColumnB, ColumnC, ColumnD)

Функция «горизонтальная». « Горизонтальная» функция, потому что оперирует колонками (или n параметрами, и количество их конечно, к сожалению, и всегда должно быть задано), а не записями.

Max функция – «вертикальная», потому что оперирует со записями – берет максимально возможное значения поля из n-записей.

Аналог Max функции в «горизонтальном» исполнении Greatest, для Min функции – функция Least, а для Avg нет аналогичной функции. Почему? Редко используется?

Для Coalesce нет аналога «вертикальной» функции, впрочем, аналог был бы бессмысленным.

Вообще Oracle после функции DECODE могли все эти «горизонтальные» функции и не создавать. Она настолько универсальная.

GREATEST реализовывался «простой» конструкцией (для трех полей попробуйте написать сами – получится очень удобная и читаемая конструкция):

DECODE(Sign(ColumnA-ColumnB), 1, ColumnA, -1, ColumnB, ColumnA)

Больше built-in функций – меньше кода, читаемость лучше, да и понятливость тоже.

Сколько людей — столько мнений. Однозначно разделить на bad и best practice не выйдет.

Using non-deterministic functions directly in conditions. +1 Использование функций в условиях (WHERE) — зло и жестоко бьет по производительности.

Catch-all error handling. 0 — Зависит от выбранного Вами способа обработки ошибок. Будет ли логирование уже на DB уровне или все ошибки наверху обрабатывать.

Client access as object owner. +1. Для внешних приложений должно быть определенно API, на каком уровне его делать это другая задача, но пускать «козлов в огород» не стоит.

Client access to tables. +1. Меньше знаешь — лучше спишь, про write можно вообще забыть, читать позволить можно лучше через views либо через API.

Embedding complex SQL code into PL/SQL. -1. Не понял, что же здесь плохого.

Error handling with magic numbers. 0 — «it’s depend». Все зависит от способа обработок ошибок, — какой из них лучший или правильный, или более удобный решать Вам.

Error handling with output parameters. +1. Несмотря на предыдущий пункт. Процедура с REF CURSOR OUT и OUT переменой индицирующий успешный вызов или нет — откроет Вам глаза на проблему.

Formatting data in views. +1. Конвертация типа Date в строку — типичная проблема. Зачем это делать? (А ведь делают.)

Hardcoding local Varchar2 variable size +1. Только это относится ко всем типам, а не только к VARCHAR2, Случаи использования для переменных NUMBER(5) и присваивать туда значение из поля с типом NUMBER(12), а еще лучше NUMBER(24,8), довольно частые.

Ignoring exceptions. +1. Только здесь речь идет не об игнорировании — речь идет о «сокрытии» ошибок.

begin
…
Exception
   When others then
        NULL;
end;

Not using bound variables for changing parameters. +1. Оптимизатору надо помогать, а не запутывать его.

Relying on conditional column predicates in triggers. +2 Костылями надо пользоваться только в крайних случаях.

Relying on context information in package variables. +2 Глобальные переменные не есть хорошо. Таблиц мало?

Relying on external context initialisation. 0 == +1 + -1. Но без комментариев, Потому что решение тоже не понравилось.

Secondary processing with unshielded triggers. +2. Почему смотрите выше.

Storing ROWID for later reference. +1. Есть sequences.

Storing empty LOBs. +1. Вообще, зачем их хранить?

Too many levels of views. +1. Oracle system views видели? План выполнения видели? Для некоторых в 40 строк не умещается.

Transactional control in non-autonomous procedures. +1. Наступал.

Trigger depending on order of execution. +2. Почему? Смотрите выше.

Using Sequence nextval without curval. +1 Странно? Потому что читать надо как «Using currval without call of nextval».

Using a sequence as a counter. +1. По моему все очевидно.

Using bound variables for constants. 0. — Проблема существуют, но решение подходит только к определенному случаю. Вы знаете список значений их характер распределения значений. Вероятность не очень большая.

Using derived column values for existence checks. +1 Все прозрачно и ясно.

Using exceptions for flow control. +1. Зачем так делать? Пример надуманным выглядит.

Using magic numbers for non-existing values. +1 . NULL может использоваться как «значение по умолчанию». Само значение может быть определенно в другом месте. 0 и -1 конечно это не годится. Можно конечно поспорить, но если сегодня например статьи с CategoryId = NULL означают «Разное», при этом у вас есть и статьи с такой категорий, то пробивая сразу категорию «Разное», позже их разделить будет невозможно, если вы определите что статьи с CategoryId = NULL это «Новости». (Пример, конечно, высосан из пальца.)

Using non-dedicated packages for continuous jobs. 0 — Не понял что плохого. Успешность вызова grant execute зависит от того выполняется сейчас процедура из пакета или нет?

Wrapping everything into stored procedures. Самый спорный вопрос — хорошо это или плохо. Я приверженец этого подхода, правда у меня только аргумент — такой подход позволяет скрыть структуры данных от клиентской части и модификация ее производится только на одном уровне. Вообще использование или не использование этого подхода — тема отдельной статьи.