building a web interface

Shel joralemonshelly at
Mon Nov 22 00:40:10 CET 2010

No worries at all about repeating things.  I wasn't clear, and I
appreciate your going to the trouble of teaching me just about
anything.  Even things I think I know, I might not really know :-)

Let's see... am okay with the relational design stuff.  Thanks for the
"EXPLAIN" verb.

I am confused about multiple simultaneous users, which I would like to
be able to accommodate.  On the db side, I have a structure to store
data for each user, and know a bit about selectively locking data,
although I have not implemented that yet, so will see what happens.

I don't really get how multiple users work in terms of pretty much
everything else, like if the Python code is running on the server,
then... well, I just don't know.  Maybe I should try to get it running
for multiple discrete users first, and then think about simultaneous
users, or is that a bad way to go about things?  Or maybe it will
start to make more sense when I get into building the interface?  Any
info/suggestions are very welcome.

Thanks again!


On Nov 21, 4:51 am, Martin Gregorie <mar... at address-in-sig.invalid>
> 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