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! Shel On Nov 21, 4:51 am, Martin Gregorie <mar...@address-in-sig.invalid> wrote: > 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 | -- http://mail.python.org/mailman/listinfo/python-list
