Является ли база данных документов / NoSQL хорошим кандидатом для хранения баланса?

Question

Если бы я создал базовую систему персонального учета (потому что я такой - это хобби-проект о домене, с которым я достаточно знаком, чтобы не увязнуть в требованиях), был бы NoSQL / база данных документов как RavenDB быть хорошим кандидатом для хранения учетных записей и, что более важно, транзакций с этими учетными записями? Как выбрать, какой объект является «документом»?

Я подозреваю, что это один из тех случаев, когда база данных SQL была на самом деле является правильным выбором, и попытка перейти на NoSQL - ошибка, но потом, когда я думаю о том, что мало что знаю о CQRS и источнике событий Интересно, является ли сущность / документ на самом деле Учетной записью , а транзакции События сохраняются против него, и что, когда происходят эти "события", возможно, мое приложение также затем выписывает в легко запрашиваемое хранилище для чтения, например, в базу данных SQL.

Большое спасибо заранее.

Answer 1

Вы, конечно, можете создать такую ​​систему. В этом сценарии у вас есть агрегат учетных записей, а также агрегат TimePeriod. Периодом времени обычно является Месяц, Квартал или Год. Внутри каждого TimePeriod у вас есть транзакции за этот период. Это означает, что загрузка текущего состояния очень быстрая, и у вас есть полный журнал, в котором вы можете вернуться назад. Причина TimePeriod в том, что это обычно граница, на которой вы на самом деле думаете о таких вещах.

Answer 2

Лично я думаю, что это хорошая идея, но я немного предвзят, потому что моя работа на полный рабочий день - это создание системы учета, основанной на CQRS, Event Sourcing и базе данных документов.

Вот почему:

Источник событий и бухгалтерский учет основаны на том же принципе. Вы ничего не удаляете, вы только изменяете. Если вы добавили неправильную транзакцию, вы не удалите ее. Вы создаете офсетную транзакцию. То же самое с событиями, вы не удаляете их, вы просто создаете событие, которое отменяет первое. Это означает, что вы публикуете много TransactionAddedEvent.

Далее, если вы ведете двойной учет, запись транзакции отличается от того, как вы просматриваете ее на экране (особенно в балансе). Следовательно, мне снова нравится cqrs. Мы можем хранить данные, используя правильные принципы учета, но наша модель чтения может быть оптимизирована для отображения данных так, как вы хотите их просматривать.

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

Таким образом, в вашем документе db у вас будет коллекция записей.

Это делает запрос очень простым. Если вы хотите просмотреть все записи для учетной записи, просто скажите SELECT * FROM Entries WHERE AccountId = 1. Я знаю, что это SQL, но все понимают простоту этого запроса. Это так же просто в документе БД. Плюс, это будет молниеносно.

Затем можно создать баланс с группировкой запросов по учету и установлением ограничения на дату. Обратите внимание, что объединения вообще не нужны, что делает документ БД отличным выбором.

Answer 3

В этом случае реляционная база данных является наиболее подходящей, поскольку у вас есть реляционные данные (например, строки и столбцы)

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

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

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

Answer 4

Если вы немного покопаетесь в теории и истории бухгалтерского учета, то увидите, что «документами» должны быть исходные документы - заказ на покупку, счет-фактура, чек и т. Д.Бухгалтерские записи представляют собой стандартизированные сводки этих обычно читаемых человеком исходных документов.Бухгалтерская транзакция - это две или более записей, которые объединяют две или более учетных записи, связанных с балансированием дебетов и кредитов.Остатки на счетах, отчеты, такие как баланс или отчет о прибылях и убытках, и т. Д. - это просто сводные данные об этих транзакциях.

Думайте об этом как о многоуровневой архитектуре - исходные документы, несбалансированные записи, сбалансированные транзакции, а затем финансовые отчеты.

Исходные документы являются «единственным источником правды», а не записями, которые их обобщают.Вы всегда должны быть в состоянии восстановить всю базу данных из исходных документов.В некотором смысле, БД - это всего лишь указатель на исходные документы.Слишком много людей забывают об этом и пишут бухгалтерские программы, в которых сами транзакции считаются источником правды.Это вызывает необходимость в целой «другой системе хранения и документооборота для самих исходных документов», и вы сталкиваетесь с типичным современным корпоративным беспорядком.

Если вы работаете с какой-то моделью событий, топравильное место для использования события - прикрепить к нему исходный документ.Затем событие инициирует анализ этого документа в правильных учетных записях.Этот анализ может быть выполнен программно, если исходный документ уже является цифровым, или вручную, если источником является лист бумаги или неформатированное сообщение - звучит как начало системы рабочего процесса, верно?Вы все еще хотите сохранить этот оригинальный исходный документ где-нибудь.БД документа кажется хорошей идеей для этого, особенно если он поддерживает схему, где вы можете связать исходные документы с их результирующими проанализированными и сбалансированными записями и наоборот.