#1 is what I would do; I've implemented designs like that for financial
accounting in SQLObject.
Why is it difficult to scale? What's the difficulty with the Joins?
Fleshing out Oleg's comments...
class Account(SQLObject):
name = StringCol()
description = StringCol()
creationDate = DateCol()
class CutAccount(Account):
cutDate = DateCol()
class Transaction(SQLOBject):
date = DateCol()
amount = DecimalCol()
class CreditCardTransaction(Transaction):
creditCard = ForeignKey('CreditCard')
class CreditCard(CutAccount):
validityDate = DateCol()
creditLimit = DecimalCol()
transactions = MultipleJoin('CreditCardTransaction')
class CheckingTransaction(Transaction):
checkingAccount = ForeignKey('CheckingAccount')
class CheckingAccount(CutAccount):
transactions = MultipleJoin('CheckingTransaction')
Object model something like that.
cs
On Friday 15 February 2008 07:19:51 Michael Adonay wrote:
> Hello guys,
>
> I am a bit new about this SQLObject approach to things, so I was thinking
> that maybe developing my current project in Python/SQLObject would help me
> develop some skills, but I have reached a point in which I need guidance.
>
> In my project I am going to be working with financial accounts, Credit
> Cards, Savings accounts, Checking accounts, etc... The issue I am stalled
> at is that I do not know how to store the data that are specific to each.
>
> A simplified example of what I am trying to do is:
>
> All accounts have:
> - name
> - description
> - creation date
>
> Credit Cards have:
> - credit limit
> - cut date
> - validity date
>
> Checking Accounts have:
> - also have a cut date
>
> So, my question is:
>
> How should I design my tables to store the data?
>
> I have thought of some alternatives myself, which are:
> 1 - Creating a separate table for each type, which would be difficult to
> 'scale' from and also a bit difficult to track transactions (would be a
> mess at the time of making 'joins' etc..)
> 2 - Creating a single table for all (would make me a big bothersome table
> that has blank fields/columns taking up some beautiful space, and it
> wouldnt be as organized as the next alternative).
> 3 - Creating one table that holds the information that all accounts have,
> and one table that holds the specific information of each type.
>
> Even though this is not a homework or school project at all, I felt free to
> ask a teacher, when I was working on #2 (since I discarded #1 more or less
> since the begining), and he pointed me to #3 for efficiency, and I thought
> maybe I should ask here for more experienced users to point me on the right
> direction on the implementation of this project (or maybe a good link or
> book to read) using python/sqlobject.
>
> Any suggestions/comments/references are welcome.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
