Проектирование сущностей, сервисов и репозиториев

Обсуждаем, как правильно строить приложения
sda
Сообщения: 301
Зарегистрирован: 2013.12.19, 09:29

Re: Проектирование сущностей, сервисов и репозиториев

Сообщение sda » 2017.11.14, 23:40

samdark innodb в mysql появился в 2001. До этого момента поддержка транзакций отсутствовала.

Аватара пользователя
samdark
Администратор
Сообщения: 8585
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Проектирование сущностей, сервисов и репозиториев

Сообщение samdark » 2017.11.15, 00:52

Я про то, что ACID-транзакции были задолго до MySQL.

anton_z
Сообщения: 251
Зарегистрирован: 2017.01.15, 15:01

Re: Проектирование сущностей, сервисов и репозиториев

Сообщение anton_z » 2017.11.15, 02:23

sda писал(а):
2017.11.14, 17:39
Но если посмотреть на реальный мир, то там все бизнес-процессы это eventual consistency, а не ACID. Потому что там нельзя сделать роллбек. Там конечный автомат. Бизнесмен решает, что ему делать если операция была неудачной. Например клиент съел заказ в ресторане, но оплатить его не в состоянии. Роллбек сделать невозможно. Можно лишь сделать какую-то компенсирующую операцию. Побить клиента например. Шутка. Я думаю, что в информационных системах мы также должны описывать бизнес-процессы в виде конечного автомата. ACID не работает в SOA архитектуре. ACID не существовал во времена доминирования MyISAM и я не смог найти как тогда решали проблему консистентности. Но очень интересно. Не думаю, что просто надеялись на лучшее :mrgreen:
Бесусловно, многие вещи в этом мире нетранзакционны, но не стоит натягивать жизнь на чисто технический критерий, которым является ACID.
Как правило rollback в РСУБД используется не для того, чтобы отменить уже совершенную операцию, а сделать атомарным выполнение какой-то конретной операции. У вас может быть и ACID и Eventual Consistency, это вещи не взаимоисключающие. Eventual Consistency - Immediate Consistency - вот антагонисты.

По поводу того, чем пользовались до появления транзакзакций - видимо чем-то не очень удобным, раз в итоге пришли к транзакциям.
Да с масштабированием проблемы, нужно их как-то решать (и то если один сервер РСУБД перестает справляться или проект изначально проектируется как высоконагруженный, заложены огромные деньги на рекламу) опираясь на специфику конкретного кейса. И здесь вам транзакции все равно пригодятся, только скорее всего выполняться они будут не в обработчике HTTP-запроса, а в воркере, который будет обрабатывать задания из очереди.

Ответить