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

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

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

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

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

В смысле откаты? :)

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

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

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

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

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

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

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

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

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

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

http://www.sql.ru/forum/actualtopics.aspx?search=%E1%E8%EB%EB%E8%ED%E3&submit...

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

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

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

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

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

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

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

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

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

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

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