Здравствуйте, gandjustas, Вы писали:

G>·>Так ведь вопрос идёт об архитектуре. Откуда так получилось, что разные независимые физические сущности оказались в одной БД? Склад, корзина пользователя, каталоги товаров — всё лежит в одном монолите... Удобно, конечно, но работает плохо, т.к. неверно моделирует реальность.
G>А в чем смысл "верно моделировать реальность"? тем более что у слов "верно" и "реальность" очень субъективное понимание?
G>Я думаю есть единственно верный способ моделирования — отталкиваться от конкретных решаемых задач. Если нам нужно транзакционно обновить состояние корзины с резервов на складе, то они должны быть в одной базе и работать в одной транзакции.
А откуда возникла такая задача "транзакционно обновить состояние корзины с резервов на складе"? По-моему, ты путаешь цель и средство.

Аналогия. Мне это напоминает давнишние споры cvcs vs dvcs. Ну как типа "нам нужно точно пронумеровать каждый changeset, как в svn. А вот git так не умеет, значит отстой". Вот только git точнее описывает реально происходящее при работе с исходниками, а не случайно придуманные "нам нужно". Не бывает в ральном мире точно пронумерованных changesets. Поэтому svn умер.

G>>>В рамках одного процесса вполне себе бывает.
G>·>Ну вот плохо получается, если моделировать одним процессом.
G>Тогда можно атомарность сделать за счет одной бд на одном сервере.
G>СУБД умеет обеспечивать атомарность изменений в рамках одного сервера\бд. Прям гарантировано умеет, в отличие от наколеночных поделок.
Да не важно. СУБД это просто такой готовый процесс.

G>·>Участники бизнес-процессов в реальном мире — независимы, географически распределены, работают параллельно.
G>Как это связано? Если они все приходят в итоге на одни сервер? бд например, то задача решаема.
Мы можем попытаться их заставить, реализуя такую монолитную архитектуру. И это даже как-то будет работать. Пока этот один сервер не ляжет.

G>>>Тут дело не в транзакции выдачи со склада, тут вы транзакционность потеряли парой шагов бизнес-процесса ранее.
G>·>Это разные транзакции в разных частях системы.
G>И что? Все равно потеряли.
G>В рамках бизес-процесса бывают шаги, где нужна транзакционно, а бывает что не нужна. Я же описывал что резервирование товаров на складе и смена статуса заказа на "зарезервирован" должны быть в одной транзакции
А как это решит твою проблему "пользователь плюет на это дело и идет в другой магазин"? Какую вообще проблему решает эта твоя "одна транзакция"?

С таким же успехом резервировать можно в одной транзакции, а обновлять статус заказа на "зарезервирован" в другой. Вот только в этом случае транзакция резервирования выполняется в БД склада, а транзакция смены статуса в БД заказов. И эти БД могут быть физически распределены и размещены поближе к местам событий.

G>·>В мелкомасштабных проектах работает, да. А так банально даже не в версии дело, а скажем, есть Azul и Oracle. С разной стоимостью, лицензиями и разными свойствами. Да даже просто ключи запуска могут отличаться.
G>И это повод не пользоваться транзакциями?
Это повод не использовать один процесс. И транзакции, если ими пользоваться, будут распределёнными. Что кошмар и ужас.

G>>>У меня в проекте сейчас работает C# 10-летней давности. Да, неэффективно по сравнению с текущей версией, но работает.
G>·>Именно. А начнёшь переезд — заколебаешься для большого проекта.
G>Так у меня большой проект. За 10 лет огого сколько всего написали.
Так и я о том же. В рамках МСА была бы группка мелких проектов, то можно было бы есть слона по частям. А сейчас ты в тупике.

Здравствуйте, gandjustas, Вы писали:

G>·>Так ведь вопрос идёт об архитектуре. Откуда так получилось, что разные независимые физические сущности оказались в одной БД? Склад, корзина пользователя, каталоги товаров — всё лежит в одном монолите... Удобно, конечно, но работает плохо, т.к. неверно моделирует реальность.
G>А в чем смысл "верно моделировать реальность"? тем более что у слов "верно" и "реальность" очень субъективное понимание?
G>Я думаю есть единственно верный способ моделирования — отталкиваться от конкретных решаемых задач. Если нам нужно транзакционно обновить состояние корзины с резервов на складе, то они должны быть в одной базе и работать в одной транзакции.
А откуда возникла такая задача "транзакционно обновить состояние корзины с резервов на складе"? По-моему, ты путаешь цель и средство.

Аналогия. Мне это напоминает давнишние споры cvcs vs dvcs. Ну как типа "нам нужно точно пронумеровать каждый changeset, как в svn. А вот git так не умеет, значит отстой". Вот только git точнее описывает реально происходящее при работе с исходниками, а не случайно придуманные "нам нужно". Не бывает в ральном мире точно пронумерованных changesets. Поэтому svn умер.

G>>>В рамках одного процесса вполне себе бывает.
G>·>Ну вот плохо получается, если моделировать одним процессом.
G>Тогда можно атомарность сделать за счет одной бд на одном сервере.
G>СУБД умеет обеспечивать атомарность изменений в рамках одного сервера\бд. Прям гарантировано умеет, в отличие от наколеночных поделок.
Да не важно. СУБД это просто такой готовый процесс.

G>·>Участники бизнес-процессов в реальном мире — независимы, географически распределены, работают параллельно.
G>Как это связано? Если они все приходят в итоге на одни сервер? бд например, то задача решаема.
Мы можем попытаться их заставить ходить на один сервер, реализуя такую монолитную архитектуру. И это даже как-то будет работать. Пока этот один сервер не ляжет.

G>>>Тут дело не в транзакции выдачи со склада, тут вы транзакционность потеряли парой шагов бизнес-процесса ранее.
G>·>Это разные транзакции в разных частях системы.
G>И что? Все равно потеряли.
G>В рамках бизес-процесса бывают шаги, где нужна транзакционно, а бывает что не нужна. Я же описывал что резервирование товаров на складе и смена статуса заказа на "зарезервирован" должны быть в одной транзакции
А как это решит твою проблему "пользователь плюет на это дело и идет в другой магазин"? Какую вообще проблему решает эта твоя "одна транзакция"?

С таким же успехом резервировать можно в одной транзакции, а обновлять статус заказа на "зарезервирован" в другой. Вот только в этом случае транзакция резервирования выполняется в БД склада, а транзакция смены статуса в БД заказов. И эти БД могут быть физически распределены и размещены поближе к местам событий.

G>·>В мелкомасштабных проектах работает, да. А так банально даже не в версии дело, а скажем, есть Azul и Oracle. С разной стоимостью, лицензиями и разными свойствами. Да даже просто ключи запуска могут отличаться.
G>И это повод не пользоваться транзакциями?
Это повод не использовать один процесс. И транзакции, если ими пользоваться, будут распределёнными. Что кошмар и ужас.

G>>>У меня в проекте сейчас работает C# 10-летней давности. Да, неэффективно по сравнению с текущей версией, но работает.
G>·>Именно. А начнёшь переезд — заколебаешься для большого проекта.
G>Так у меня большой проект. За 10 лет огого сколько всего написали.
Так и я о том же. В рамках МСА была бы группка мелких проектов, то можно было бы есть слона по частям. А сейчас ты в тупике.