Mailing List Archive: designing question

designing question

Jul 19, 1999, 12:36 AM

Post #1 of 5 (344 views)

I have the mission to develop a rather big database front-end
application. Since the application must be multi-platform LINUX -WIN it
will be developed in Python.

For infomatiion, this is what will be used :
Python of course
Tk
Pmw
Gadfly

I have two questions:
1. The database will hold abouth 50.000 lines in its biggest table, can
gadfly handle this without problems, what abouth acces time ??

2. The application will have abouth 50 different inputscreens wich acces
all to different tables.
I will create a class for every window wich inheret from a general
'input-screen'-class.
I wonder if a should place the db-access code (insert-update-delete) in
every specific window or if i should create a big db class wich has all
possible db-acces in it ?
Ex :
Possibility 1 :
class window :
def __init__
..
def createwidget:
...
def handlevents :
...
def insertrecord :
...
def deleterecord:
....
def update record :
....
Possibility 2:
class window
def __init__
..
def createwidget:
...
def handlevents :
call here db().inserttable1()
db().updatetable1()
db().deletetable1()

class db
def __init__:
connect to db
def inserttable1
..
def updatetable1
...
def deletetable1
...

Hope my question is clear and sorry for the bad english, i'm french :)

Pierrette

designing question [ In reply to ]

bucodi at worldnet

Jul 19, 1999, 6:09 AM

Post #2 of 5 (342 views)

Permalink

Gordon McMillan wrote:

> Pierrette writes:
>
> > I have two questions:
> > 1. The database will hold abouth 50.000 lines in its biggest table,
> > can gadfly handle this without problems, what abouth acces time ??
>
> Gadfly is in-memory, and (to support transactions) has 2 copies of
> the db. If the machines have the memory, access time will be fine.

With the cost of memory now this should be no problem :) All machines we
have or that we deliver to clients has at least 128 MB

>
>
> > 2. The application will have abouth 50 different inputscreens wich
> > acces all to different tables. I will create a class for every
> > window wich inheret from a general 'input-screen'-class. I wonder if
> > a should place the db-access code (insert-update-delete) in every
> > specific window or if i should create a big db class wich has all
> > possible db-acces in it ?
>
> Completely philosophical question. For flexibility, I favor the GUI
> making no assumptions about how the data is stored. I would have the
> GUI making calls like "app.addthingie(thingie)", where the app has an
> "abstract" UI.

I'm surprised that this is just a philosophical question :) I tought
there would be some
practical reasons to do it one or another way (p.e. maintenance of the
application)
The reason i posted this question is that i have very little experience
with OOP. (actually i learned it with python <wink>) So i'm looking for
some experience here

>
>
> Of course, it almost nevers works out that cleanly in practice, but
> it's certainly a worthy goal.
>
> Now if each screen maps exactly to a table, this is probably
> overkill. But if your data is normalized, this makes a lousy UI -
> users usually want to know all kinds of silly things, like whether
> there's a "next" record, or the owning customer's name (not the
> foreign key in this row, which is just a number) that violate
> normalization.
>
> - Gordon

Thanks for your quick response Gordon

Pierrette

designing question [ In reply to ]

gmcm at hypernet

Jul 19, 1999, 6:23 AM

Post #3 of 5 (342 views)

Permalink

Pierrette writes:

> I have two questions:
> 1. The database will hold abouth 50.000 lines in its biggest table,
> can gadfly handle this without problems, what abouth acces time ??

Gadfly is in-memory, and (to support transactions) has 2 copies of
the db. If the machines have the memory, access time will be fine.

> 2. The application will have abouth 50 different inputscreens wich
> acces all to different tables. I will create a class for every
> window wich inheret from a general 'input-screen'-class. I wonder if
> a should place the db-access code (insert-update-delete) in every
> specific window or if i should create a big db class wich has all
> possible db-acces in it ?

Completely philosophical question. For flexibility, I favor the GUI
making no assumptions about how the data is stored. I would have the
GUI making calls like "app.addthingie(thingie)", where the app has an
"abstract" UI.

Of course, it almost nevers works out that cleanly in practice, but
it's certainly a worthy goal.

Now if each screen maps exactly to a table, this is probably
overkill. But if your data is normalized, this makes a lousy UI -
users usually want to know all kinds of silly things, like whether
there's a "next" record, or the owning customer's name (not the
foreign key in this row, which is just a number) that violate
normalization.

- Gordon

designing question [ In reply to ]

andy at robanal

Jul 21, 1999, 2:22 PM

Post #4 of 5 (342 views)

Permalink

pserrand <bucodi@worldnet.fr> wrote:

>> > 2. The application will have abouth 50 different inputscreens wich
>> > acces all to different tables. I will create a class for every
>> > window wich inheret from a general 'input-screen'-class. I wonder if
>> > a should place the db-access code (insert-update-delete) in every
>> > specific window or if i should create a big db class wich has all
>> > possible db-acces in it ?
>>
>> Completely philosophical question. For flexibility, I favor the GUI
>> making no assumptions about how the data is stored. I would have the
>> GUI making calls like "app.addthingie(thingie)", where the app has an
>> "abstract" UI.
>
>I'm surprised that this is just a philosophical question :) I tought
>there would be some
>practical reasons to do it one or another way (p.e. maintenance of the
>application)
>The reason i posted this question is that i have very little experience
>with OOP. (actually i learned it with python <wink>) So i'm looking for
>some experience here
>
With 50 screens, it is going to be complex. I'd suggest first
modelling the 'objects' your program deals with. Thus, if it is an
invoicing program, you make objects which represent the invoices,
customers, payments etc in as natural a way as you can. Build
Python classes and play with them at the interactive prompt; you can
do this faster in Python than in anything. If the object model is
right, then building a natural GUI on top of it and a database behind
it are fairly straightforward tasks; and the program is easy to
extend.

Good luck,

Andy

designing question [ In reply to ]

aaron_watters at my-deja

Aug 13, 1999, 6:07 AM

Post #5 of 5 (341 views)

Permalink

In article <1279735663-4809742@hypernet.com>,
gmcm@hypernet.com wrote:
> Pierrette writes:
>
> > I have two questions:
> > 1. The database will hold abouth 50.000 lines in its biggest table,
> > can gadfly handle this without problems, what abouth acces time ??
>
> Gadfly is in-memory, and (to support transactions) has 2 copies of
> the db. If the machines have the memory, access time will be fine.

This is sortof true and sortof deceptive.

The shadow copies of a table share most of their structure
with the committed copies most of the time (ie, they are python
lists that contain pointers to shared structures most of the time)
and shadow copies are only created when a table is updated but
not yet committed. So really almost always gadfly has only one
copy of almost every data item in the database (unless you update
huge numbers of rows before a commit).

And the answer is... If you have enough memory gadfly should work
fine. If you don't you *might* see a serious performance reduction
(unless most of the accesses are via indices in which case it's
hard to say). Good luck. Sorry I missed this before. Look to
the www.egroups.com gadfly-rdbms mailing list for some other
discussions and benchmarks.

-- Aaron Watters http://www.chordate.com

===

Winston, if you were my husband, I'd poison your tea.
Madame, if you were my wife I'd drink it.

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.