building a web interface

Martin Gregorie martin at address-in-sig.invalid
Sun Nov 21 13:51:01 CET 2010

On Sat, 20 Nov 2010 17:20:53 -0800, Shel wrote:

> Sorry I wasn't clear about the db part.  Most of the data has already
> been written and/or generated and tested with the code.  I do plan to
> finish all the database stuff before going to the front end, but am just
> thinking ahead about how to do the interface.
That sounds good. Sorry if I was repeating stuff you already know, but it 
wasn't obvious what you knew about care & feeding of an RDBMS. I'll just 
add two comments on databases:
- Decompose the database design to 3NF form and make sure all prime
  and foreign keys have indexes. This is stuff that previous experience
  shows self-taught Access users don't do. Not doing it will bite you
  hard on performance as soon as the tables exceed a few rows in size.
  Fixing it later can force major changes to the programs as well.

- If you haven't looked at it yet, find out about the EXPLAIN verb
  and what its output means. Use it on all queries that your online
  program issues and take notice of how rearranging the query and/or
  adding/changing indexes affects the cost of the query. Lower cost
  queries mean higher performance and hence faster response times.

What I meant to add last night is that, if your application is to be used 
by more than a single user at a time a prime consideration is how you 
will recognise input received from each user and how you'll store their 
context between interactions with them in the same session and keep each 
session's context separate. The web server doesn't do this, so this 
managing session context is the application's responsibility. Common 
methods are to use a session cookie and/or to store session context in 
the database.

martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

More information about the Python-list mailing list