Огормное спасибо!
Эта книга мне попалась в 11-ом классе, в 90-м году. В то время у меня был доступ к OS/360 и я реализовал на ней одну из задач — многопользовательскую игру про ресурсы и фабрики. Это был мой первый такой достаточно большой код на паскале и часть по взамодействия между виртуальными машинами на ассемблере. Эх, ностальгия…
Да, теперь понятно, почему каждый по-своему прав.
В рамках BASE-архтектуры такое возможно, когда скорость важна.
Для банков, мобильных операторов и т.п — только ACID — жертвуем скоростью доступа для обеспечения консистентности.
Да, redo- самое слабое место. Именно поэтому до сих пор несмотря на наличие всяческих рэйдов и репликаций на уровне массивов oracle рекомендует создавать как минимум два лога в каждой группе :)
В приципе — да, но это же не от хорошей жизни, а резальтат исторически сложивихся обстоятельств. Насколько было бы проще, если бы все жило в одной БД :)
Так что для нового цельного проекта изначально стараться распределить даные по разным БД — это нонсенс.
Да ради бога, абстрагируйтесь на здоровье.
Только не надо опускаться до уровня БД и рассказывать, что данные могут лежать по разным БД, а то ведь вам поверят, а потом расхлебывай :)
Вопрос, сможет ли этот промежуточный кэш пройти тот же ACID-тест?
Про тупик для многих компаний было бы интересно почитать.
Самые объемные и нагруженные БД, имхо, моибльных операторов — вполне себе живут в OLTP части на одном сервере, в части DWH возможен RAC.
Вот, хорошо. Так речь о том, что если проводки и баланс лежат в разных БД, то вы не сможете обеспечить между ними соотвествие — может пропасть одно из двух полностью, либо в выписке по счету в определенный момент времени у вас не сойдется начальный баланс, сумму по проводкам и конечный баланс.
Не знаю, как еще доступнее объяснить :)
Хорошо. Например Вы — банк, у Вас есть входящий баланс счета на дату, проводки по нему и исходящий баланс. То, что появление новой проводки изменяет баланс — это бизнес-логика или нет?
А бизнес логика при том, что она должна быть обеспечена некими механизмами, которые гарантировано работают.
Вот, Вы готовы держать платежи и балансы в разных БД, а я Вам объясняю, почему этого делать нельзя :)
Oracle Instant Client
Или это какой-то другой клиент?
:)))
на страничке pdf-ка со списком.
Может возродиться? :)
Эта книга мне попалась в 11-ом классе, в 90-м году. В то время у меня был доступ к OS/360 и я реализовал на ней одну из задач — многопользовательскую игру про ресурсы и фабрики. Это был мой первый такой достаточно большой код на паскале и часть по взамодействия между виртуальными машинами на ассемблере. Эх, ностальгия…
В рамках BASE-архтектуры такое возможно, когда скорость важна.
Для банков, мобильных операторов и т.п — только ACID — жертвуем скоростью доступа для обеспечения консистентности.
Так что для нового цельного проекта изначально стараться распределить даные по разным БД — это нонсенс.
Только не надо опускаться до уровня БД и рассказывать, что данные могут лежать по разным БД, а то ведь вам поверят, а потом расхлебывай :)
Про тупик для многих компаний было бы интересно почитать.
Самые объемные и нагруженные БД, имхо, моибльных операторов — вполне себе живут в OLTP части на одном сервере, в части DWH возможен RAC.
Не знаю, как еще доступнее объяснить :)
Вот, Вы готовы держать платежи и балансы в разных БД, а я Вам объясняю, почему этого делать нельзя :)