MySQL should be able to handle a few hundred thousand records comfortably. Given the usage scenario, you will need to let the users log on with a textual username and password to access their data, and perhaps store a few other personal details (like e-mail address, performance data) and, of course, the save game data.
You could use a session-based connection with the server if you have lots of users switching machines at random. You could construct the web player so as to force the user to log on each session, rather than “remembering” the last user - you could still use cookies under this scheme. From experience, I would say it is easier to implement a session-based server app using Ruby/Rails rather than PHP, since Rails has excellent built-in support for sessions. However, you may, of course, prefer PHP from the point of view of existing knowledge, more hosting options, etc.
I can’t see any reference to the POST method in the Unity WWW class docs, although I suppose it’s possibly a 2.0 feature (?) However, I think you could use Application.ExternalCall to call some AJAX code in the embedding web page and transfer data that way. You could use (browser) JavaScript to send an XMLHttpRequest to your server (with as much data as you like) and then store it in an “invisible” HTML construct in the page. Then, you could have another JS function to retrieve that data using the DOM. Call these JS functions from your web player and you have an inelegant but usable communication channel. I believe passing binary data via XMLHttpRequest is problematic, so you might need to encode your save games in base 64 before transfer. (HEALTH WARNING: I’ve never tried this technique for transferring data, but it seems reasonable!)
Save game performance might be an issue - you may get many hits in quick succession if, say, a teacher suddenly tells a class to save and log off when the school bell rings. You can probably improve the speed of the database somewhat if you separate out the “cold” fields from the save data and put them in their own table. Again, Rails makes this very straightforward to manage. Both Rails and PHP are basically “shared nothing” systems, so they will scale straightforwardly if you need to add extra servers to cope with demand (and the scaling-up should be transparent to the client web player).
You should also protect against SQL injection and other possible server attacks. There is a very handy “top ten” of common attacks and countermeasures at the OWASP Project website.
Your user performance data should be quite easy to generate from the saved games and, of course, the obvious way to publish it is via a website. Again, Rails will make it very easy to have an admin page for each school, accessible via a log-on, but it’s also perfectly possible with PHP.
I’ll post again if I think of anything else…