lockyХм... а что, я могу перемежать, скажем, DML и DDL в pl/sql?
В PL/SQL Вы можете, скажем, перемежать DML и операторы управления транзакциями. Не можете перемежать DML и DDL. Внимание, вопрос: сколько же в результате мы получаем языков, почему именно столько и какое отношение к этому имеет возможность перемежать?

lockyв любом случае, в пл/скл граница куда более четкая, нежели в т-скл.
На практике - безусловно, куда более четкая. Правда, по моим, возможно неверным, представлениям это вызвано исключительно одной деталью - неявным возвратом рекордсетов, наличествующим в T-SQL. Согласитесь, например, что между


и


разницы, особенно внешней, не так много (и к сожалению не каждый ораклоид расскажет, в чем эта разница состоит). И по аналогичным причинам не особо видна разница между


и


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

lockyЯ, кстати, тоже не знаю - было интересно узнать, для "общего образования".
Главным различием я бы назвал следующее:


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

lockyбольше всего лично мне не нравится путаница в типах данных между скл и пл/скл. обычно это вроде как не сильно важно, но иногда встреваем :(
Лично меня раздражает отсутствие boolean в SQL. А вообще... сейчас это малоактуально, а в восьмерке очень мешало - делаешь запрос, отлаживаешь, все отлично, вставляешь в PL/SQL - а он, сволочь, не компилируется. Типа "эта фича SQL в PL/SQL не поддерживается".

lockyа булеан... ну, обойтись можно
Можно, но глупо. Получается буквально следующее: я пишу функцию с результатом boolean, какую-нибудь проверку. В один прекрасный день мне хочется использовать ее в запросе, и наступает бред. Какое решение ни принимай - все, мягко говоря, не лучшее.

lockyпроведя опыты - мне не показалось, что это "общий принцип атомарности"
Тем не менее, это так и есть. Чтобы увидеть это, сравните, например, в моем примере (с i < 3)


и

lockyнабор стейтментов трактуется либо как набор (в первом случае),
Тут следует еще учесть, что в Oracle нет понятия "скрипт" или аналогичного (как в MS, если не ошибаюсь, batch). Набор стейтментов в первом случае - это server call с клиента для каждого insert-а поочередно.

lockyхотя - на то блок и есть блок.
Можно провести аналогию со вложенными транзакциями.

Bogdanov AndreyА на мой взгляд, нарушение этого принципа крайне странно.
А я вполне понимаю обе точки зрения :)

Сугубо формально можно сказать, что "когда сервер за меня что-то откатывает - это не есть хорошо, может я собирался исправить проблему и продолжить с места остановки". Однако на практике это удачное соглашение; я не припомню, чтобы оно мне мешало, зато в ряде случаев оно делает хороший код проще, а тупой код - надежнее.

Bogdanov AndreyИ если операция недопустима (типа исключение произошло), то автомат не меняет свое состояние.
Как мы с Вами знаем, в ряде аспектов состояние все-таки меняет. Поэтому выбор оказывается "в чем меняется, а в чем нет" - и это уже не вопрос формальной теории, вопрос практики.

Bogdanov AndreyЭта позиция, на мой взгляд, крайне непродуктивна.
Согласен. Я просто "истины ради" указал на возможность раскритиковать этот подход со стороны некоего также истинного утверждения (давайте не углубляться в детали атомарности... мне кажется, ситуация понятна - например, если я делал большой-большой апдейт, и он слетел на миллионной записи, я хочу повторить его с where id >= 1000000.

Как я уже указал выше, мне нравится этот оракловый подход по сугубо статистическим причинам (нередко удобно, никогда не мешает).

StXКонтрпример - PostgreSQL, чистый версионник. За очень малым исключением (создание/удаление базы, tablespace и сборки мусора) DDL в транзакции допустим и работает абсолютно корректно. Почему орден св.Оракла это запрещает?
Коллега Yo отчасти горячится, но в его словах есть доля истины. Давайте я выдам одно очевидное соображение, а вы уж решайте, что есть чистый версионник и корректная работа.

Утверждение: корректный внутритранзакционный DDL возможен только при serializable изоляции в жестком смысле этого слова (в том самом, в котором в Oracle вообще нет serializable) Обосновать это очень просто: представьте себе, что я делаю в транзакции некоторое изменение структуры таблицы, несовместимое со старой. Скажем, alter table drop column или alter table add foreign key. Далее в той же транзакции я делаю запрос к модифицированной таблице и как-то использую полученные данные. Проблема в том, что при любом уровне ниже serializable я при этом должен получить записи, параллельно вставленные другими транзакциями в старую версию структуры. Это выливается в проблемы либо на физическом уровне - то самое нет колонки, несовпадение форматов - либо, что куда страшнее, на логическом (новая логика захавала неконвертированные старые данные, нарушена целостность).

Теперь давайте подумаем, что есть serializable в этом случае. На самом деле это ни что иное как эксклюзивная блокировка таблицы или иного крупного объекта (да еще и возможно с растущими из него). То есть решить эту задачу мы можем только блокировкой в худшем неверсионном стиле.

Прошу прощения, я не спал ночь, может завтра подумаю получше и решу, что неправ