My 2 cents on the stopping duplicate votes would be to log the IP AND the PHP Session ID. Maybe, using MySQL, make the primary key a double-field with the IP and the SessionID as the key.
The reason I suggest this is because there are a LOT of organizations where many machines are represented by one IP - for example where I work. This means that if I voted at work, then nobody else at my work could vote.
If you did session ID's then the plus point would be that votes would be unique to an individual's session. The negative point would be that all it takes is for the user to delete their cookie or empty their cache and, as far as the server is concerned, they are a new user. This is why I suggest logging the IP also. Maybe also log the unix timestamp for the vote too (that way you could use some funky SQL to keep an eye out for spikes in votes.
This is simply the way *I'D* do it... I have a habit of over-complicating/planning for edge cases.
Another option open to you, which might not be AS educational as doing it yourself, is to use a CMS such as Drupal which handles Polls, voting, blogs, comments, etc. It also handles all this 'security' stuff for you or at least gives you a platform to work upon which is inherently a 'bit' secure - for example, in Drupal an SQL insert query would be written...
db_query('INSERT INTO {blah} (timestamp, body) VALUES(%d, "%s")', time(), $body);
In that snippet the db_query function is a 'core' function which is part of the database layer which allows Drupal to work on MySQL, PostGr SQL and I believe they have a working Oracle model too. The table name has a {} wrapped around it as this allows the db_query function to rewrite table names to all have custom prefixes. The REALLY funky bit is the placeholders. '%d' represents a decimal number - any variable that gets put in here its forced to be a number first. The '%s' tells Drupal that a string is going in that place - all strings get escaped and sanitized on entry. The other arguments to the function are the variables which get placed in the %d, %s and other placeholders.
As for putting your username/password into a separate PHP document in a non-accessible place... I'm not personally sure how effective this really is. Ever if you had a separate include PHP file, as long as it doesn't echo anything out itself then even if you called it manually, it wouldn't ACTUALLY tell you anything. For example, all drupal installs store the database username and password in a file called 'settings.php' which is stored in your 'sites' folder under yous specific site folder (a single Drupal install can host multiple sites). For example, you might have it in 'http://www.example.com/sites/example.com/settings.php'. This file simply defines a load of configuration options - if you access it directly then you still cant do anything with it.
[center]
