LINUX.ORG.RU

[реквестирую-тред] Написание финансовых приложений на Java


0

1

Ищу статьи/книги на сабжевую тему. Нужно будет писать что-то вроде биллинга. Хочется заботать матчасть прежде. В первую очередь интересует представление денег и типовые схемы БД ну и подводные камни.

★★★★★

> В первую очередь интересует представление денег и типовые схемы БД

Это всё круто, но про транзакции не забудь :)

const86 ★★★★★ ()

и подводные камни.

Сразу думай про произвольные данные, привязываемые к транзакции, и индексацию по ним.

baverman ★★★ ()
Ответ на: комментарий от const86

Про транзакции помню. С ними тоже непонятки. Как избежать гонки? Например на счет 10.0, и я хочу снять 5.0. Считываю 10.0, проверяю, что 10.0 - 5.0 будет >= 0, выполняю транзакцию. В этот момент выполняется другая транзакция, которая снимает со счета 6.0. В итоге на счете будет -1.0. Как быть? Тригер, проверяющий, что счет положителен? Выставить уровень изоляции SERIALIZABLE? Сделать оптимистическую блокировку путем добавления поля-версии к счету? Тогда при выполнении всех транзакция добавлять «where version=?». Если кто-то параллельно поменяет значение счета, то транзакция не выполнится. Какие есть еще решения?

dizza ★★★★★ ()
Ответ на: комментарий от baverman

Сразу думай про произвольные данные, привязываемые к транзакции, и индексацию по ним.

А можно чуть по-подробнее? Что за данные такие?

dizza ★★★★★ ()
Ответ на: комментарий от dizza

Что за данные такие?

Реквизиты — основания транзакции, будь то бумажка (платежка, счет) или какая-нибудь sms. То есть, вся допинфа, которая нужна для поиска биллингуемого объекта, а также причины, почему проводится именно такая сумма.

Например, при подаче платного объявления, аттачится не только общая сумма, но и все скидки, и основания, почему были сделаны такие скидки.

Это потом сильно помогает при построении отчетов и разборках с клиентами.

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

baverman ★★★ ()
Ответ на: комментарий от dizza

В итоге на счете будет -1.0. Как быть?

Есть задачи, в которых это не суть важно. У тебя точно требуется строжайший учет?

baverman ★★★ ()
Ответ на: комментарий от baverman

> В итоге на счете будет -1.0. Как быть?

Запретить операции со счетом пока операция не завершена, строить очередь операций.

Megamozg ()
Ответ на: комментарий от deterok

>А если забыл бы? - Представь себе, в банке вывеску:«шанс перевода 50%! Только у нас!»

Никогда не забуду, как в банке на работающей базе приходилось исправлять (чужие) ошибки прямым запросом update. Во была веселуха!

ttnl ★★★★★ ()
Ответ на: комментарий от baverman

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

А немутабельные, это когда вместо изменения значение счета создается новая запись в БД с пометкой, что она более новая?

dizza ★★★★★ ()
Ответ на: комментарий от Megamozg

Т.е. SERIALIZABLE уровень изоляции транзакций спасет отца русской демократии :)?

dizza ★★★★★ ()
Ответ на: комментарий от dizza

А немутабельные

Это когда транзакции, после создания, больше не трогаются. Любые исправления, только через дополнительные проводки.

baverman ★★★ ()
Ответ на: комментарий от dizza

В свое время я использовал транзацкии на уровне БД.

trex6 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.