On 10/08/2019 09:48, mhysnm1...@gmail.com wrote: > HI all, > > I have multiple different accounts that I am creating reports for. Thus I > cannot have a centralised transaction table that contains all the records. > These different accounts are for different organisations or for other > members in my family.
That shouldn't make any difference. It would be impractical to have different tables for each customer or organisation in something like a large utility company or say., Amazon where there will be literally millions of account holders. You would need millions of tables which would be a nightmare to manage. The standard model for these kinds of scenarios is a single account table with a reference to the customer(or user) table and a transaction table with a reference to the account. That supports the concept of multiple customers, each with (potentially)multiple accounts and each account having multiple transactions. > I hope this explains what I am trying to do. I am trying to make things as > dynamic as possible without myself recoding the model. You can make it as dynamic as you like using a single table and you certainly shouldn't need to recode the model, although I'm not familiar with SQLAlchemy (which is the ORM wrapper you are using I think?) But you might need to tweak you object definition to make it single table based. > Also was wondering if it was possible as well. Anything is possible, it just takes more effort. In this case quite a lot more effort. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor