Встреча с разработчиком MySQL Дмитрием Леневым

В частности, речь пойдёт о том, как в MySQL добавляли транзакции

через одно место, вестимо, даже SQLite умеет DDL в транзакциях, а MySQL - нет

Видео будет?

DDL в транзакциях

Это шутка? Такое даже быдлокодом не назовешь, скорее анацефалокодом.

Скорее всего да.

Это шутка? Такое даже быдлокодом не назовешь, скорее анацефалокодом.

можешь смело направить свое обращение разработикам оф. гуя под MySQL - MySQL Workbench, который при синхронизации модели на половине выдает ошибку и оставляет БД в сломанном состоянии

П.С. проверял ес-но на тестовом сервере, MySQL вообще не пользуюсь

Мальчика в инвалидном кресле возьмите.

Ждём видео

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

«Разработчик, программирующий с помощью мышки, разработчиком не является, пора бы это уже запомнить. »

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

чем он лучше postgresql?

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

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

Лучшая информация о MySQL это инструкция по переходу на Postgresql.

Транзакции нужны только для данных. Если не можешь определиться со схемой хранения данных - бери MongoDB, там с таким быдлоархитектом гораздо лояльнее.

А требовать ROLLBACK всяких ALTER TABLE'ов - все равно, что, отсосав негру, кричать «а вот и не было, я в домике!».

А требовать ROLLBACK всяких ALTER TABLE'ов - все равно, что, отсосав негру, кричать «а вот и не было, я в домике!».

В квотезы!

Если не можешь определиться со схемой хранения данных

и еще один теоретик, который умеет быдлоархитектить продумать БД из сотен таблиц на годы вперед

А требовать ROLLBACK всяких ALTER TABLE'ов - все равно, что, отсосав негру, кричать «а вот и не было, я в домике!».

тебе виднее

и еще один теоретик, который умеет быдлоархитектить продумать БД из сотен таблиц на годы вперед

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

Ну и скажи-ка мне, что будет с transaction log, если ты сделаешь выборку из таблицы на пару гигабайт в новую таблицу, а старую дропнешь. И прикинь, каким раком встанет СУБД, если ты потом сделаешь ROLLBACK.

Но изменения должны быть инкрементальными - и транзакции тут лишний оверхед.

согласен, их тоже надо далеко не всегда применять

Ну и скажи-ка мне, что будет с transaction log, если ты сделаешь выборку из таблицы на пару гигабайт в новую таблицу, а старую дропнешь. И прикинь, каким раком встанет СУБД, если ты потом сделаешь ROLLBACK.

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

С такими ломающими изменениями схемы все делается гораздо проще. Либо пользователи вышибаются/изолируются в «плановый перерыв», либо нужно идти в обход - вместо переименования поля заводить новое, создавать версионные вьюшки и т.д. А насчет частного случая - при разработке СУБД нужно предусмотреть ВСЕ частные и граничные случаи. И весь этот гемоорой ты предлагаешь ради того, чтобы не ломалось непроверенное на тестовом сервере обновление? Разработчик тоже не желает бежать за негром, ловить его и вдувать обратно, у него есть более важные цели.

интересно

когда у них появится мулти-мастер репликация официально

Либо пользователи вышибаются/изолируются в «плановый перерыв»,

главное, чтоб он не затянулся, если вдруг во время обновления что-то пошло не так

либо нужно идти в обход - вместо переименования поля заводить новое

создание нового поля и копирование всех данных - отличный повод поставить раком СУБД (с)

И весь этот гемоорой ты предлагаешь ради того, чтобы не ломалось непроверенное на тестовом сервере обновление?

а) это экономия времени в том числе на тестовом сервере б) проверенное обновление точно также может навернуться, данные на рабочем сервере - другие, а это уже повод обломаться на униках, например, или на блокировках, да - такие изменения и ошибки бывают крайне редко, я на такое вообще не попадал, но 100% гарантии на успешное применение изменений ни у кого нет

создание нового поля и копирование всех данных - отличный повод поставить раком СУБД (с)

Ты думаешь, в транзакции это не будет делаться, да? У меня для тебя плохие новости.

уже повод обломаться на униках, например, или на блокировках

«облом на униках» == «я тупой долбоёб, который при обновлении не делает предварительных проверок на коллизии». А боишься блокировок - вышибай пользователей или принудительно лочь все объекты.

100% гарантии на успешное применение изменений ни у кого нет

Ну так транзакции тебя при этом точно не спасут, а уж как они усложнят СУБД и затянут сами DDL, похоже, тебе вряд ли объяснишь.

кто пойдёт, спросите у него, почему не работают check constraints?

CREATE TEMPORARY TABLE - ы?

Ты думаешь, в транзакции это не будет делаться, да? У меня для тебя плохие новости.

не будет, в WAL или журнал лягут только данные о таблице, но не из нее

«облом на униках» == «я тупой долбоёб, который при обновлении не делает предварительных проверок на коллизии»

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

уж как они усложнят СУБД

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

и затянут сами DDL

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

не будет, в WAL или журнал лягут только данные о таблице, но не из нее

и при смене типа поля?

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

хочешь, чтобы обновление выполнилось консистентно, а не прерывалось посередине - сначала все проверь и не начинай, если есть проблемы.

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

Ага, и сделать этакую ограниченную транзакционность, которую можно будет применять только при сферическо-вакуумных условиях. И что делать, если в эту транзакцию врезается нетранзакционная команда? Правильно - коммитить. В лес.

И что делать, если в эту транзакцию врезается нетранзакционная команда?

проверить код запроса на наличие нетранзакционных команд и отказаться выполнять?

стиви, лежи и не рипайся. А если этот SQL с терминала идет построчно? Да и смысла тогда в такой транзакции мало - обновление точно так же упадет, как если без транзакций.

А если этот SQL с терминала идет построчно?

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

и при смене типа поля?

уже писал

хочешь, чтобы обновление выполнилось консистентно, а не прерывалось посередине - сначала все проверь и не начинай, если есть проблемы.

ок, я mysql почти не знаю, но спрошу - есть таблица T1, в ней PK - f1, нужно создать T2 с FK на T1, простейший случай, что мне надо проверить?

Ага, и сделать этакую ограниченную транзакционность, которую можно будет применять только при сферическо-вакуумных условиях. И что делать, если в эту транзакцию врезается нетранзакционная команда? Правильно - коммитить.

я уже приводил примеры связанных изменений, которые легко ложатся на отдельные транзакции, назови свой пример, где «в транзакцию врезается нетранзакционная команда», тогда можно будет говорить об уместности применения этих изменений вместе

Ну и скажи-ка мне, что будет с transaction log, если ты сделаешь выборку из таблицы на пару гигабайт в новую таблицу, а старую дропнешь. И прикинь, каким раком встанет СУБД, если ты потом сделаешь ROLLBACK.

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

Либо пользователи вышибаются/изолируются в «плановый перерыв», либо нужно идти в обход - вместо переименования поля заводить новое, создавать версионные вьюшки и т.д.

А вот в постгресе это почему-то не нужно. Можно все просто завернуть в транзакцию. Наверное, разработчики постгреса тупые, великого DBA всея Руси Анонимуса не читали, что надо через жопу делать, и сделали нормально. На кол их, еретиков!

предварительных проверок на коллизии

Между проверкой и изменением проходит ненулевое время, дурачина. Race condition — слыхал, есть зверь такой?

Между проверкой и изменением проходит ненулевое время, дурачина. Race condition — слыхал, есть зверь такой?

Есть еще один зверь - Global table lock. В этом случае становится пофиг и на «ненулевое время», и на возгласы людей с собакой-алкашом на аватаре.

есть таблица T1, в ней PK - f1, нужно создать T2 с FK на T1, простейший случай, что мне надо проверить?

Для собственно создания таблицы - ничего не надо, создастся и так. А вставка новых данных будет завязана на PK f1 и замечательно ляжет в транзакцию.

назови свой пример, где «в транзакцию врезается нетранзакционная команда», тогда можно будет говорить об уместности применения этих изменений вместе

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

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

Для собственно создания таблицы - ничего не надо

как минимум надо проверить какой engine у T1

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

большой объем данных - всегда ограничение, которое очень часто вносит свои коррективы в самые разные аспекты работы с СУБД, на небольших объемах - исключения делать не надо