файл отрицательного размера

Вот уже SQL-сервер под линукс готовят: https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/

Может, заодно и Internet Explorer под линукс сделают наконец? А то некоторые [идиотские] сайты только с IE нормально работают..

Оригинал этой записи в личном блоге.

В одной базе данных есть две таблицы, связанные отношением 1:M. Скажем, в одной лежат посты из блога, а в другой комментарии, привязанные к постам по id.
Задача: перетащить их все в другую базу, в которой идентификаторы у постов изменятся (потому что там уже есть другие посты с теми же id, что в первой базе), но при этом сохранить привязку к ним комментариев.

С постами понятно, SELECT из первой базы и INSERT во вторую.

А вот как быть с комментариями?
Мне пока пришли в голову три идеи, но все неэффективные.

1) Для каждого поста сразу после помещения его во вторую базу, когда уже известны и старый, и новый id, найти в первой базе все комментарии по старому id и сложить их во вторую базу с новым id. Но это отдельный SQL-запрос на каждый пост, а их там дофига.

2) Сначала перенести все посты, попутно составляя табличку со старыми и новыми id, а потом переносить комментарии, заменяя id постов по этой табличке. Но если табличку держать в памяти, она получится очень нефигового размера. А в базах её создавать нельзя, правов не хватает.

3) Извлечь вместе с постами сразу все их комментарии путём LEFT OUTER JOIN. Но тогда каждый пост извлечётся целиком много раз, с каждым своим комментарием, это дикий перерасход памяти в SQL-сервере.

Как бы это сделать поэффективнее?

Оригинал этой записи в личном блоге.

Имеется скрипт. Выполняет довольно простую работу:
соединяется с базой данных (Informix, как водится), создаёт временную таблицу, заполняет её данными из других таблиц.
Потом запускает на эту таблицу SELECT COUNT(*), ну так, чисто для отчётности, и выводит это количество в лог.
Потом создаёт в таблице индекс для ускорения последующих операций и запускает UPDATE STATISTICS, чтоб индекс заработал.
Затем удаляет из таблицы некоторые ненужные данные посредством DELETE, опять запускает SELECT COUNT(*) и… внезапно случается облом:

execute failed: SQL: -710: Table has been dropped, altered or renamed.

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

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

Потом подумали, что может это на сервере регулярно проводятся какие-то работы как раз когда скрипт по крону запускается. Но нифига, он падает в одном и том же месте в любое время дня и ночи. Вот пока идёт первоначальный INSERT, таблица есть, первый SELECT — есть, DELETE — всё ещё есть, а на следующем SELECT‘е через пару секунд — уже нет. Мистика какая-то..

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

Подсказка: скрипт использует перловый DBI. То есть, запросы сначала подготавливаются посредством prepare(), а потом уже выполняются вызовом execute(). Запрос про SELECT COUNT(*) запускается несколько раз, после каждого изменения в таблице, но он всегда одинаковый, поэтому для него применяется prepare_cached(), это немножко ускоряет работу.

Оригинал этой записи в личном блоге.
Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме.

Пишем простейшую хранимую процедуру, которая умеет иногда генерировать исключения:

CREATE PROCEDURE tmp_proc (
  p_foo int
)
  IF p_foo = 0 THEN
    RAISE EXCEPTION -746, 0, "tmp_proc-raised exception";
  END IF
END PROCEDURE;

Вызываем её из перла посредством DBD::Informix:
“EXECUTE PROCEDURE tmp_proc (p_foo = ?)”, prepare, execute..

Как ожидалось, получаем

DBI::err = '-746', DBI::errstr='SQL: -746: tmp_proc-raised exception'

Преобразуем процедуру в функцию:

CREATE PROCEDURE tmp_func (
  p_foo int
)
RETURNING int;
  DEFINE foo int;
  IF p_foo = 0 THEN
    RAISE EXCEPTION -746, 0, "tmp_func-raised exception";
  END IF
  LET foo = p_foo+1;
RETURN foo;
END PROCEDURE;

“EXECUTE PROCEDURE tmp_func (p_foo = ?)”, prepare, execute..

И фиг там. execute успешно отрабатывает, возвращает 0E0, DBI::err и DBI::errstr совершенно undefined, всё прекрасно, никаких ошибок.

А вот если потом вызвать fetchrow_array(), то только тогда

DBI::err = '-746', DBI::errstr='SQL: -746: tmp_func-raised exception'.

Что совсем плохо, если какой-нибудь fetch() совсем не вызывать, то функция, похоже, совсем не запускается. Либо результаты её работы откатываются. Потому что изначально я на это наткнулся на функции, которая проверяет данные, добавляет строку в таблицу и возвращает ID от добавленной строки. Вот если этот ID потом не считать с помощью fetch, то данные в таблицу вообще не попадают.

Я даже не понимаю, куда тут копать..

Оригинал этой записи. Комментировать можно тут или там.

Есть табличка tbl. В ней есть записи нескольких типов, различаются по значению поля type. Кроме того, есть поле disporder (числовое, определяет, в каком порядке записи должны показываться пользователю) и поле prio (приоритет, может быть ‘Y’ или ‘N’). Для записей типа 1 prio может быть равен ‘Y’ максимум у одной записи в таблице, а может вообще у всех быть ‘N’.

Задача: одним запросом вывести из таблицы поле title (и только его) для всех записей типа 2, а также для первых трёх (в порядке prio+disporder) записей типа 1, причём выборка должна быть отсортирована в целом по disporder, но если в выборке встречается запись типа 1, у которой prio=’Y', то она должна оказаться на первом месте.

Пользоваться можно вашим любимым диалектом SQL, а в моём для полного счастья не допускается FIRST и ORDER BY в SELECT’ах, объединенных в UNION. UNION, понятное дело, можно сортировать только целиком и только по полям, присутствующим во всех входящих в него SELECT’ах.

Оригинал этой записи. Комментировать можно тут или там.

Помогите, не дайте умереть в неведении!

Как на ANSI SQL (или на Informix-диалекте) пишется _эффективный_ запрос на апдейт многих полей в одной таблице данными из другой таблицы?

Так работает, но по-моему, это сильно неэффективный метод:

UPDATE t1 SET
c1 = (SELECT c1 FROM t2 WHERE t2.id=t1.id),
c2 = (SELECT c2 FROM t2 WHERE t2.id=t1.id),
c3 = (SELECT c3 FROM t2 WHERE t2.id=t1.id),
...
WHERE id IN (SELECT id FROM t2);

Когда поле одно, это ещё ничего, а когда их десяток, это как-то некрасиво выглядит.

Upd: на информиксовском диалекте это пишется так:
UPDATE t1 SET (c1,c2,c3)=
((SELECT c1,c2,c3 FROM t2 WHERE t2.id=t1.id))

Двойные скобки у вложенного селекта существены.

Оригинал этой записи в личном блоге.

а вот кусочек SQLного запроса:

unload to 'tmp_file' delimiter '|'
select
...
case when u.name is null then "|" when u.name like "% %" then REPLACE(TRIM(u.name)," ", "|") else TRIM(u.name) || "|" end as first_name_surname
...


вы заметили, что delimiter тоже '|', да? но это ещё ничего. потом на полученный файл запускается
sed -e 's/\\|/|/' -e 's/\\|/ /g' tmp_file>file

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

Upd: и засеките, сколько времени у вас уйдёт на решение этой задачи

(очень задумчиво) а что, в PHP'шном SQL API ещё не реализовали placeholders и binding?

Типа, как это в перловом DBD сделано: при вызове prepare() в SQLном операторе пишутся вопросики, а реальные значения передаются при вызове execute().

Можно ли считать SQL языком программирования?
А Пролог?

Upd: чтоб было понятнее, откуда возник вопрос. Они оба не являются алгоритмическими языками, в том смысле, что не содержат алгоритма получения результата. Они содержат только критерии, которым этот результат должен удовлетворять. Можно ли считать их при этом языками программирования?

Ну вылитый паскаль.

Кроме того много думал о менталитете авторов Оракла. Он у них получился весь такой логичный-логичный. Но в некоторых местах всё-таки очень ненатуральный..

Вот, например, там нет автоинкрементируемых полей. Вместо них есть sequence, из которых при необходимости можно извлечь очередное значение и засунуть его в нужное поле. При добавлении записи это можно сделать автоматически, например, триггером.
Но вот как клиент может узнать, какое именно значение попало в свежедобавленную запись? Посмотреть в sequence можно, но если в это время кто-нибудь еще вставлял запись в ту же таблицу, то sequence мог уже поменяться.
cybernatic_cat предложил весь процесс вставки завернуть в хранимую функцию, которая будет сама извлекать очередное значение из sequence, и потом его возвращать.
Да, это будет надёжно работать, но.. как-то оно совсем ненатурально по сравнению с простым и логичным MySQLным SELECT LAST_INSERT_ID() или MSSQLным SELECT @@IDENTITY.

Или я просто не умею правильно готовить этих кошек?