API RESTful для бухгалтерии или, в обход MongoDB, отсутствия типа данных DECIMAL и поддержки транзакций

Question

Я оцениваю MongoDB как хранилище для нашего финансового / бухгалтерского RESTful API. Однако я знаю об отсутствии транзакций в MongoDB и типе десятичных данных:

Полагаю, я мог бы преодолеть отсутствие десятичных дробей, сохранив их как целые числа, и разделив / умножив их на коэффициент точности по мере необходимости. Потребители будут загружать (GET) и сохранять (PUT / POST) через уровень API, что позволит мне позаботиться о преобразовании на уровне API. Хранение целых чисел позволит выполнять вычисления и атомарные обновления по мере необходимости.

Я также не вижу недостатка транзакций в MongoDB как ограничителя показа, по крайней мере, в моем случае: API REST не позволял бы выполнять огромные многократные обновления «один вызов подходит всем». Ответственность потребителя будет заключаться в реализации логики отката в случае сбоя во время «логической» транзакции (цепочка множественных последующих вызовов обновления).

«Объекты», хранящиеся в БД, будут счетами, запасами, платежами ... стандартными учетными материалами. Хотя реляционная модель данных оказалась хорошим решением для хранения данных такого типа, я не понимаю, как хранение без схемы может вызвать проблемы. Возьмите пункт счета. Я мог бы хранить каждый документ в коллекции документов с вложенными позициями. Конечно, мне все еще нужно было бы несколько коллекций: документы, платежи, контакты и т. Д., Поэтому использование коллекций MongoDB мне подходит.

Кто-нибудь делал что-то подобное хотя бы отдаленно? Я все еще на стадии разработки, поэтому я бы действительно использовал отзывы от ветеранов MongoDB / REST - спасибо.

PS: если вам интересно, я бы отлично подошел к решению RDBMS, но мне нравится рассматривать альтернативы, и я вижу некоторые преимущества, идущие без схемы. Например, MongoDB выводит JSON / BSON, с которым работает REST API. Во-вторых, отсутствие схемы означает, что я могу получить документ с переменным количеством полей и сразу же сохранить его, не беспокоясь о пропущенных полях (которые будут нулевыми в БД и потребуют большого количества if IsNULL (fieldname) при построении ответ на запрос GET) и т. д.

Answer 1

Хранение десятичных чисел в виде целых чисел - это то, что люди делают. Если вы выполните запрос функции поддержки десятичных чисел в jira MongoDB, вы увидите пару упоминаний, что это их обходной путь: https://jira.mongodb.org/browse/SERVER-1393

Обратите внимание, что коэффициент будет составлять, когда вы уменьшите карту, и все, что умножает / делит два или более таких чисел.

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

Я думаю, что это здорово - изучать новые технологии ... не собираюсь предлагать вам это. Но учтите, что без схемы действительно светит, когда вам нужно запросить эти поля. Если вы этого не сделаете, то вы можете просто сохранить их все в одном поле / столбце большого размера в документе или реляционной базе данных. (хотя, каждый раз, когда я видел, как проект делает это, они через 3 месяца должны начать запрашивать / сообщать / что-то по одному из этих сериализованных значений, и это настоящая боль).