SELECT + Транзакции

@Milord · Регистрация: 03.11.2009

Студворк — интернет-сервис помощи студентам

Доброго времени суток!
И так, в процессе разработки появилась задача записи информации в несколько таблиц БД с учетом нескольких проверок и если происходит какая то ошибка то откатить все. Как вижу решение я:
1 начинаем транзакцию
2 проверяем наличие справочников в БД.Т1
3 если все хорошо записываю основную информацию в БД.Т1
(Далее идет блок информации не определенного размера из за этого использую цикл)
4 Запускаю цикл
4.1 Проверяю свое количество с количеством в БД
4.2 Если все хорошо записываю в БД.Т2
4.3 Обновляю значение с которым сравнивали из БД
5 завершаю цикл если данные закончились иначе пункт 4.1
6 если все хорошо, то COMMIT!
Таким образом по логике или сохраняться и изменяться все или нечего.
Но для того что бы проверить наличие справочников или доступного количества нужно сделать запрос SELECT в БД, что в свою очередь прерывает транзакцию. Подскажите как решить такую проблему!
С базой данных работаю из Delphi + dbExpress. MySql 5.1.53.
З.Ы.: Как я понял запрос SELECT допустим в транзакции.

@afganec · 01.12.2011, 14:51

Я с транзакциями работал так.
Перед началом работы с базой выставлял autocommit в ноль.
Затем шла очередь запросов с проверками, и при первой ошибке выполнялся rollback в выводом соответствующего сообщения.

@Milord · 02.12.2011, 02:53 **[ТС]**

Но насколько я понимаю autocommit в ноль просто не даст автоматически записаться без COMMIT, но при этом вся процедура записи не будет одним целым (я уже подумывал так делать), потеряет свойство атомарности. То есть между запросом количества для проверки и последующим обновлением/записью может вклиниться параллельно работающий пользователь и изменить данные своим запросом, что нарушит целостность-достоверность БД! или я заблуждаюсь?

@afganec · 02.12.2011, 08:13

Milord, вообще хорошая тема, есть над чем подумать.

То есть алгоритм работы получается примерно такой.

1. Автокоммит выставляем в ноль - тут верно было написано, что не будет автозаписи в таблицу.
2. Стартуем транзакцию. Это своего рода точка восстановления, в случае сбоя откатываться будем именно на состояние до старта транзакции.
3. Выполняем набор запросов с проверкой каждого.
3.а. Все ок, все запросы выполнились без ошибок, выполняем commit.
3.б. Выполняем до первой ошибки, как только получаем ошибку делаем rollback, который как раз-таки вернет базу в исходное(на момент старта транзакции) состояние.

Это по атомарности.
То есть транзакция само по себе атомарна. Транзации InnoDB полностью соответствуют уровню ACID.

А по параллельной работе нескольких пользователей, то тут, думаю, можно настроить lock на таблицу, пока выполняется транзакция.
Вот что нарыл в документации
[Операция MySQL LOCK TABLES не знает про блокировки InnoDB на уровне строк в уже выполненном операторе SQL: это означает, что можно установить блокировку на таблицу, даже если существуют транзакции других пользователей, которые установили блокировку этой же таблицы на уровне строк. Таким образом, может оказаться, что ваши операции над таблицей будут вынуждены ожидать, если такая блокировка будет установлена другими пользователями: возможна также и взаимоблокировка. Тем не менее, это не угрожает целостности транзакций, так как при установке блокировки на таблицы InnoDB всегда соблюдается целостность. Кроме того, блокировка таблицы не позволяет другим транзакциям установить на таблицу дополнительные блокировки на уровне строки (в режиме несовместимости блокировок).]

Читал тут

@Milord · 02.12.2011, 10:13 **[ТС]**

Как то не очень хорошо получается, если в один запрос и autocommit и транзакции и еще блокировку таблиц, нагромождение какое то получается ИМХО.
Тут решили подойти с другой стороны к проблеме, можно заменить проверку наличия SELEKT на INSERT хитрым образом, вызывая ошибку при добавлении существующей записи которая свидетельствует о наличии такого в БД, а если запись прошла то вызвать ROLLBACK и откатится все в том числе добавленная запись))))
Но все же, раз в хелпах по мускулу можно использовать SELEKT значит надо все таки докумекать как)
Пробовал решить задачу в другом клиенте MySQL (SQLyog), та же шляпа, SELEKT и конец транзакции...

@afganec · 02.12.2011, 11:06

Milord, а что тебя смущает использовать select в запросах?
не могу понять...

Менять select на insert, имхо, не лучшее решение.

Autocommit можно вынести в конфиг. -1 запрос.
Залочил таблу, стартанул транзакцию, поработал с данными, завершил.

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

@Milord · 05.12.2011, 02:46 **[ТС]**

Ну первая задача это конечно опыт)))
Вторая это сохранение данных из формы многопользовательского АРМа в БД.
А форма имеет фиксированный набор общих данных и таблицу с дополнительными данными которая заполняется по мере необходимости. А дабы данные были достоверными мне нужно что бы писалась вся форма или нечего. Реализация похожа на "Клиент-КС" (буховская софтина), только на многооооо проще).
А с селектом хочу разобраться, почему так, на одном форуме писали мол это с 5й версии началось, но при этом консольный клиент работает нормально). Кто то же наверняка с этим сталкивался)

@afganec · 07.12.2011, 00:41

Milord, сорри что выпал на некоторое время из дискуссии.

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

Считываешь все данные с формы, выполняешь запрос.
Либо это update(изменение/сохранение данных) либо это insert(добавляем новые данные).

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

Если я что не так понял, поправь, пожалуйста.
А насчет целостности данных... тут надо копать в сторону lock, имхо...

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Основы отладки веб-приложений на SDL3 по USB и Wi-Fi, запущенных в браузере мобильных устройств 8Observer8 07.02.2026 Содержание блога Браузер Chrome имеет средства для отладки мобильных веб-приложений по USB. В этой пошаговой инструкции ограничимся работой с консолью. Вывод в консоль - это часть процесса. . .	SDL3 для Web (WebAssembly): Обработчик клика мыши в браузере ПК и касания экрана в браузере на мобильном устройстве 8Observer8 02.02.2026 Содержание блога Для начала пошагово создадим рабочий пример для подготовки к экспериментам в браузере ПК и в браузере мобильного устройства. Потом напишем обработчик клика мыши и обработчик. . .	Философия технологии iceja 01.02.2026 На мой взгляд у человека в технических проектах остается роль генерального директора. Все остальное нейронки делают уже лучше человека. Они не могут нести предпринимательские риски, не могут. . .	SDL3 для Web (WebAssembly): Вывод текста со шрифтом TTF с помощью SDL3_ttf 8Observer8 01.02.2026 Содержание блога В этой пошаговой инструкции создадим с нуля веб-приложение, которое выводит текст в окне браузера. Запустим на Android на локальном сервере. Загрузим Release на бесплатный. . .
SDL3 для Web (WebAssembly): Сборка C/C++ проекта из консоли 8Observer8 30.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .	SDL3 для Web (WebAssembly): Установка Emscripten SDK (emsdk) и CMake для сборки C и C++ приложений в Wasm 8Observer8 30.01.2026 Содержание блога Для того чтобы скачать Emscripten SDK (emsdk) необходимо сначало скачать и уставить Git: Install for Windows. Следуйте стандартной процедуре установки Git через установщик. . . .	SDL3 для Android: Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 29.01.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами. Версия v3 была полностью переписана на Си, в. . .	Инструменты COM: Сохранение данный из VARIANT в файл и загрузка из файла в VARIANT bedvit 28.01.2026 Сохранение базовых типов COM и массивов (одномерных или двухмерных) любой вложенности (деревья) в файл, с возможностью выбора алгоритмов сжатия и шифрования. Часть библиотеки BedvitCOM Использованы. . .

@Milord 4 / 4 / 0 Регистрация: 03.11.2009 Сообщений: 91

	SELECT + Транзакции 01.12.2011, 05:43. Показов 3584. Ответов 7 Метки нет (Все метки) Доброго времени суток! И так, в процессе разработки появилась задача записи информации в несколько таблиц БД с учетом нескольких проверок и если происходит какая то ошибка то откатить все. Как вижу решение я: 1 начинаем транзакцию 2 проверяем наличие справочников в БД.Т1 3 если все хорошо записываю основную информацию в БД.Т1 (Далее идет блок информации не определенного размера из за этого использую цикл) 4 Запускаю цикл 4.1 Проверяю свое количество с количеством в БД 4.2 Если все хорошо записываю в БД.Т2 4.3 Обновляю значение с которым сравнивали из БД 5 завершаю цикл если данные закончились иначе пункт 4.1 6 если все хорошо, то COMMIT! Таким образом по логике или сохраняться и изменяться все или нечего. Но для того что бы проверить наличие справочников или доступного количества нужно сделать запрос SELECT в БД, что в свою очередь прерывает транзакцию. Подскажите как решить такую проблему! С базой данных работаю из Delphi + dbExpress. MySql 5.1.53. З.Ы.: Как я понял запрос SELECT допустим в транзакции. 0

@afganec 31 / 31 / 11 Регистрация: 30.06.2009 Сообщений: 148
	01.12.2011, 14:51
	Я с транзакциями работал так. Перед началом работы с базой выставлял autocommit в ноль. Затем шла очередь запросов с проверками, и при первой ошибке выполнялся rollback в выводом соответствующего сообщения. 0

@Milord 4 / 4 / 0 Регистрация: 03.11.2009 Сообщений: 91
	02.12.2011, 02:53 [ТС]
	Но насколько я понимаю autocommit в ноль просто не даст автоматически записаться без COMMIT, но при этом вся процедура записи не будет одним целым (я уже подумывал так делать), потеряет свойство атомарности. То есть между запросом количества для проверки и последующим обновлением/записью может вклиниться параллельно работающий пользователь и изменить данные своим запросом, что нарушит целостность-достоверность БД! или я заблуждаюсь? 0

@afganec 31 / 31 / 11 Регистрация: 30.06.2009 Сообщений: 148
	02.12.2011, 08:13
	Milord, вообще хорошая тема, есть над чем подумать. То есть алгоритм работы получается примерно такой. 1. Автокоммит выставляем в ноль - тут верно было написано, что не будет автозаписи в таблицу. 2. Стартуем транзакцию. Это своего рода точка восстановления, в случае сбоя откатываться будем именно на состояние до старта транзакции. 3. Выполняем набор запросов с проверкой каждого. 3.а. Все ок, все запросы выполнились без ошибок, выполняем commit. 3.б. Выполняем до первой ошибки, как только получаем ошибку делаем rollback, который как раз-таки вернет базу в исходное(на момент старта транзакции) состояние. Это по атомарности. То есть транзакция само по себе атомарна. Транзации InnoDB полностью соответствуют уровню ACID. А по параллельной работе нескольких пользователей, то тут, думаю, можно настроить lock на таблицу, пока выполняется транзакция. Вот что нарыл в документации [Операция MySQL LOCK TABLES не знает про блокировки InnoDB на уровне строк в уже выполненном операторе SQL: это означает, что можно установить блокировку на таблицу, даже если существуют транзакции других пользователей, которые установили блокировку этой же таблицы на уровне строк. Таким образом, может оказаться, что ваши операции над таблицей будут вынуждены ожидать, если такая блокировка будет установлена другими пользователями: возможна также и взаимоблокировка. Тем не менее, это не угрожает целостности транзакций, так как при установке блокировки на таблицы InnoDB всегда соблюдается целостность. Кроме того, блокировка таблицы не позволяет другим транзакциям установить на таблицу дополнительные блокировки на уровне строки (в режиме несовместимости блокировок).] Читал тут 0

@Milord 4 / 4 / 0 Регистрация: 03.11.2009 Сообщений: 91
	02.12.2011, 10:13 [ТС]
	Как то не очень хорошо получается, если в один запрос и autocommit и транзакции и еще блокировку таблиц, нагромождение какое то получается ИМХО. Тут решили подойти с другой стороны к проблеме, можно заменить проверку наличия SELEKT на INSERT хитрым образом, вызывая ошибку при добавлении существующей записи которая свидетельствует о наличии такого в БД, а если запись прошла то вызвать ROLLBACK и откатится все в том числе добавленная запись)))) Но все же, раз в хелпах по мускулу можно использовать SELEKT значит надо все таки докумекать как) Пробовал решить задачу в другом клиенте MySQL (SQLyog), та же шляпа, SELEKT и конец транзакции... 0

@afganec 31 / 31 / 11 Регистрация: 30.06.2009 Сообщений: 148
	02.12.2011, 11:06
	Milord, а что тебя смущает использовать select в запросах? не могу понять... Менять select на insert, имхо, не лучшее решение. Autocommit можно вынести в конфиг. -1 запрос. Залочил таблу, стартанул транзакцию, поработал с данными, завершил. Если не секрет, какую задачу вы решаете? Быть может после того, как пойму, что вы хотите и ответы будут более содержательны. 0

@Milord 4 / 4 / 0 Регистрация: 03.11.2009 Сообщений: 91
	05.12.2011, 02:46 [ТС]
	Ну первая задача это конечно опыт))) Вторая это сохранение данных из формы многопользовательского АРМа в БД. А форма имеет фиксированный набор общих данных и таблицу с дополнительными данными которая заполняется по мере необходимости. А дабы данные были достоверными мне нужно что бы писалась вся форма или нечего. Реализация похожа на "Клиент-КС" (буховская софтина), только на многооооо проще). А с селектом хочу разобраться, почему так, на одном форуме писали мол это с 5й версии началось, но при этом консольный клиент работает нормально). Кто то же наверняка с этим сталкивался) 0

@afganec 31 / 31 / 11 Регистрация: 30.06.2009 Сообщений: 148
	07.12.2011, 00:41
	Milord, сорри что выпал на некоторое время из дискуссии. Если честно, то не могу до конца понять, что именно вызвало трудность. Считываешь все данные с формы, выполняешь запрос. Либо это update(изменение/сохранение данных) либо это insert(добавляем новые данные). Не зная всей архитектуры вашего приложения, осмелюсь предположить, что это можно сделать одним запросом. И даже транзакции не понадобятся. Если я что не так понял, поправь, пожалуйста. А насчет целостности данных... тут надо копать в сторону lock, имхо... 0