According to your scenario an accounting system is a more complex system that requires high performance. It can be written in any language but as the system grows some programming languages will experience performance issues python being one of them take a case like Dropbox which was originally written in python but because of python speeds and data handling limitations it led the team to introduce other languages (Go, Rust) . Since you've decided to go with Django then it's best you use raw queries and concurrency etc inorder to achieve high performance.It also comes down to your hardware and code practices . Take a look at the Django ledger repo an accounting system. About the API you can explore Graphql.
On Sun, Jul 14, 2024, 8:48 PM Krishnakant Mane <kkprog...@gmail.com> wrote: > Hi Eric. > > Can you explain a bit more on the "performance " aspect you refered to? > > I have already mentioned my scenario and given the case study which I am > working on. > > In that reference, how using the ORM will benefit more than raw queries > working with materialised views? > > Regarding security, I (and the team working on this ) are totally aware of > the pitfalls and the way around them so that's out of the way. > > Regards. > > > On 7/14/24 12:32, eric paul wrote: > > In whatever way possible use the Django ORM for security purposes and also > efficiency . I won't recommend to use Raw queries if you don't know what > you are doing > > On Sun, Jul 14, 2024, 7:34 AM Enock Deghost <enockdegh...@gmail.com> > wrote: > >> 🙄 >> >> On Sun, 14 Jul 2024, 6:15 am Krishnakant Mane, <kkprog...@gmail.com> >> wrote: >> >>> Hello. >>> >>> I am seasoned SQLAlchemy user and quite good in node's sequelise ORM. >>> >>> But I am new to the one with Django.So here's my situation. >>> >>> I am developing an accounting (book keeping ) automation software >>> service. >>> >>> So there are accounting rules (Debit = Dr and credit = Cr) for double >>> entry book keeping. >>> >>> Every transaction will have 2 or more amounts, at least 1 each for dr or >>> Cr. >>> >>> These entries are called vouchers. >>> >>> We also store retail bills, receipts and payments again all in different >>> tables. >>> >>> But the bills and receipt&payment tables are connected to the voucher >>> table. >>> >>> The software generates reports such as cash flow, meaning day's opening >>> balance, total Drs, total crs, and final closing balance (DRs - Crs). >>> >>> then there are Profit and Loss as well as balance sheet reports. >>> >>> All this needs a lot of aggregations (sum and counts ) and also joining >>> of invoice + voucher and recept&payment + voucher tables. >>> >>> so here are my questions. >>> >>> 1: given the fact that I have created materialised views in Postgresql, >>> should I even care to model them and use the ORM syntax instead of raw >>> query? What would perform better? >>> >>> 2: datasets are going to be huge some times in terms of shear rows (all >>> transactions aka vouchers ) or some times sum and count will be used in >>> complex queries on a huge dataset. >>> >>> Again, should I rely on raw queries or will ORM plan the queries for me >>> better? Should I instead create stored procedures and call them from my >>> REST API? >>> >>> talking of which, >>> >>> 3: I am using Django REST Framework and serialising records is an option >>> to get json output. >>> >>> Should I use it or just go with raw queries and convert output to JSON >>> as required? >>> >>> Again performance is a question. >>> >>> Tip, My team is very proficient in SQL and yours truely can modestly >>> call himself an expert in the same, so maintenance is not an issue here. >>> >>> Regards. >>> >>> Krishnakant. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-users+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-users/097a6e55-c30e-491e-bf43-86e4c672faa4%40gmail.com >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-users+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/CAA2jrmJ0TtbxmfXeSCq5S9p8XsrPjJBf6_gKMRY_MSuTagFt4Q%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-users/CAA2jrmJ0TtbxmfXeSCq5S9p8XsrPjJBf6_gKMRY_MSuTagFt4Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CALv%3Dr_nWJjrSk%3DLbFh-pfL5Ni%2B%2ByZu0qH%3DRU7o7mnpD-eJHcqw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CALv%3Dr_nWJjrSk%3DLbFh-pfL5Ni%2B%2ByZu0qH%3DRU7o7mnpD-eJHcqw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALv%3Dr_mgDtMtaoC-4mav0c79JgH1m-dRC_PL_GU9tVCV8rjypg%40mail.gmail.com.
