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

Reply via email to