Home Original page

designing question

pserrand bucodi at worldnet.fr
Mon Jul 19 09:09:23 EDT 1999 
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
More information about the Python-list mailing list