Предлагаю рассмотреть пример.

Есть некая финасово промышленная группа ( ФПГ) , под нее открыта кредитная линия
в $1 000 000 и лимитом расходов $100 000 в день на всю группу.
В группе 20+ предприятий у каждого свои текущие счета.
У каждого свой лимит расходов по общей кредитной линии в день.
Система при недостатке средств для текущих расходов пердприятия автомтом
берет деньги из соотвествующих счетов ФПГ или кредитной линии ФПГ ( генерирует соотвествующие провдки под конкретную транзакцию).
У каждого из предприятий минимум по 5 бухгалтеров , которые могут формировать исходящие документы в рамках установленніх лимитов расходов ,
Но не видят баланса всей ФПГ( меньше знаешь крепче спишь) .

Риторический вопрос ,
Как построить систему, что бы UNDO ( Консистентное чтение) случайным образом не эмитировал и не глотал деньги нарушая лимиты расходов ,
банковский баланс и баланс ФПГ?


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

Yo.!я же пытаюсь донести то, что есть тьма задач где бизнес хочет реалтайма


Yo.!а на длинном отчете практически наверняка каша не устроит,


Взаимоисключающие параграфы детектед


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


Попробуйте сейчас заставить бухгалтера читать длинный отчет
вместо однокласников или фейсбука .
Ответственные от такой работы вертят носом, как мы от СУБД без ACID
А безотвественные безаппеляционно переводят стрелки на программеров.


Yo.!по примеру кредитной линии - ну да, конкретно в этом случае подход оптимистический подход не применить. тут пессимистический подход версионника мало чем будет отличаться от блокировочника. да, наверно еще много можно придумать задач где подходы будут схожи, но это не отменяет тьму OLTP задач где блокировочник не сможет эффективно эмулировать подход версионника.


Версионник - очень удобный механизм, не буду спорить, но не панацея.
Я с точки зрения удобства проектирования задач с песемистичным блокированием,
без него все еще никуда , для OLTP учетной системы , выбрал бы базу которая поддерживает RR в соответствии со стандартом ( на уровне всей транзакции).
А отчетную систему поставил бы на версионник.

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


DПрикольно. Одни говорят что по минному полю ходить не надо, а другие с детства там бегают и все мины знают :)

+1

Bogdanov AndreyinterestingВерсионник - очень удобный механизм, не буду спорить, но не панацея.В рамках данного топика и нет смысла искать "панацею", важно то, что одно и то же ПО для версионника и для блокировочника надо писать по-разному, причем отличие обычно не в мелких технических деталях. Соответственно перевод с одного на другой связан с определенными трудностями, требующими существенного перепроектирования.

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

Обьем рефакторинга будет определяться тем насколько приложение
изначально было правильно спроектировано , и как поменялся тип нагрузки
за время жизненного цикла старой версии ПО.

Исходя их этого и выбирать.

С точки зрения бизнеса , лучше ничего не делать ( не мигрировать) ,
чем тратить ресурсы на перенос костылей и граблей из одной системы в другую.

Если решение о миграции ( рефаторинге) принимается без достаточной
на то агрументации для тех кто за это платит , зачит откатинг детектед,
на что уже намекалось.

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

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