Перейти к содержимому


Условие запуска вычисления "До вставки в таблицу"


Сообщений в теме: 5

#1 useYourBrain

    Новичок

  • Пользователи
  • Pip
  • 2 сообщений

Отправлено 14 Апрель 2016 - 05:54

Добрый день,

А почему среди триггеров вычислений нет события "Перед сохранением/вставкой"?

Приведу реальный пример: пусть продается некий дорогостоящий товар (таблица "Товары"), на поставку которого заключается договор (таблица "Договоры"), причем оплата по договору может быть договорной - вся сумма сразу либо рассрочка: "Договор" имеет поле-список "Тип оплаты"=[Сразу|В рассрочку] и соответственно два поля "Рассрочка: Годовой процент", "Рассрочка: Срок в месяцах". Обязательными для заполнения поля отметить не могу, т.к. тип оплаты может быть разный. Таким образом еще до вставки в таблицу необходимо убедиться в корректности введенных данных и если что-то не так - вообще не записывать ничего в базу, ибо сохранение чревато дальнейшими ошибками - человек может просто не заметить того, что сделал, а более того еще и пойти вносить платежи в ошибочный договор.

Проверять и удалять запись внутри вычислений "Сохранение в таблице" не предлагать - риск сбоя есть всегда и запись просто повиснет в базе.

JavaScript тоже - это проверка только на стороне клиента. В его обход всегда можно подсунуть на сервер любые данные - достаточно его просто отключить. Так надежные приложения не разрабатываются.

И встречный вопрос - есть ли 100% гарантия, что после вставки/обновления записи вычисления обязательно будут вызваны и отработают до конца, а в ином случае база останется в нетронутом состоянии? Работает ли ваше ядро по такому алгоритму?

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

/* Подключаемся к базе */
$link = mysqli_connect(...);

/* >> В обязательном порядке открываем новую транзакцию, прежде чем что-то изменять << */
mysqli_autocommit($link, FALSE);

/* Обновляем данные записи в таблице в рамках транзакции */
mysqli_query(...);

/* Вызываем вычисления по триггеру "Сохранение в таблице" */
calc_save();

/* >> И только после всех этих действий закрываем транзакцию << */
mysqli_commit($link);


Как еще более строгий вариант - передавать в вычисления кроме $line еще и объект $link, обязав разработчика конфигурации работать только через него и в конце самому вызывать commit транзакции. И вот тогда любая работа с записями действительно будет одной цельной операцией. Иначе при любом сбое между инструкциями - сбой по питанию, например - который произойдет до завершения вычислений - и в базе окажется непредсказуемый хаос. Запись есть, а другие данные, с ней связанные окажутся испорчены или вообще не успеют появиться. Целостность данных должна быть в приоритете, ведь вы согласны?

#2 CbCoder

    Активный участник

  • Программист ООО "КБ"
  • PipPipPip
  • 8 655 сообщений
  • Пол:Мужчина
  • Город:Казань

Отправлено 16 Апрель 2016 - 18:49

Цитата

Работает ли ваше ядро по такому алгоритму?

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

#3 Slava.Aurim

    Активный участник

  • Пользователи
  • PipPipPip
  • 40 сообщений
  • Пол:Мужчина

Отправлено 18 Апрель 2016 - 00:39

Для описанной Вами ситуации вполне подходит JS (показ и скрытие нужных/ненужных полей, интерактивные инструкции к полям, сообщения об ошибках в реальном времени, проверка данных при отправке формы). Это убережет от 99% непреднамеренных ошибок.

Для гарантированной проверки на стороне сервера - Вы можете после проверки ставить флаг (что-то вроде "успешной проверки данных" или "завершённой транзакции") в скрытое поле, и позже проверять - не осталось ли некорректных (из-за сбоя) записей.

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

#4 maksn

    Активный участник

  • Пользователи
  • PipPipPip
  • 313 сообщений
  • Пол:Мужчина

Отправлено 19 Апрель 2016 - 17:59

Просмотр сообщенияuseYourBrain (14 Апрель 2016 - 05:54) писал:

А почему среди триггеров вычислений нет события "Перед сохранением/вставкой"?
Но ведь никто не мешает Вам повесить нужные триггеры на SQL сервер. Хоть BEFORE, хоть AFTER.
Конечно "не камильфо" - затрется при обновлении/восстановлении. Но уверенность в правильности данных будет.

Дополню, как пожелание. Почему бы разработчикам не включить в штатную процедуру бэкапа не только таблицы, но и полную структуру БД?. Триггеры и stored procedures - нормальные составляющие любой реляционной СУБД и не понятно почему они не включаются в бэкап

Перенос бизнес логики с уровня приложения на уровень данных значительно повышает надежность, а без триггеров этого сделать не получится

Сообщение отредактировал maksn: 20 Апрель 2016 - 09:33

"...Сижу, паяю. CRM починяю..."
Мои разработки

#5 wondertalik

    Активный участник

  • Пользователи
  • PipPipPip
  • 1 154 сообщений
  • Пол:Мужчина
  • Город:Кривой Рог, Украина

Отправлено 20 Апрель 2016 - 16:35

Просмотр сообщенияmaksn (19 Апрель 2016 - 17:59) писал:

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

#6 maksn

    Активный участник

  • Пользователи
  • PipPipPip
  • 313 сообщений
  • Пол:Мужчина

Отправлено 25 Апрель 2016 - 00:19

wondertalik сказал:

За некую казалось бы надежность
????? :blink:

Просмотр сообщенияwondertalik (20 Апрель 2016 - 16:35) писал:

в случае аварии - невероятным кол-вом времени на восстановления данных. Процедуры - еще термимо, но тригерры однозначно нет.
Хм-м...Без комментариев.

Сообщение отредактировал maksn: 25 Апрель 2016 - 00:35

"...Сижу, паяю. CRM починяю..."
Мои разработки





Количество пользователей, читающих эту тему: 1

0 пользователей, 1 гостей, 0 анонимных