building a web interface
joralemonshelly at gmail.com
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
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.
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