IF your real world problem is bigger than this simple example, you should use a transaction in conjunction with lock tables to make sure users don t overwrite each other.

Keep the logic at the DB, those semantics have mostly been solved for you.

update teams
set score = score + 1
where team_id = 1

.. or whatever score and whatever team number.

Major databases are designed to handle such situations.

When using MySQL, the InnoDB storage engine has the row-locking feature, which locks the row that is being written to. So, any update request that is for the same row will wait until the previous operation on the row completes.

If you use MyISAM storage engine, that locks the whole table when a row is being updated. That creates a choke on the server when multiple players simultaneously push update requests. So it is all about what database and particularly what storage engine you are using for the purpose.

I agree with Xepochs answer, don t introduce concurrency concerns unless you absolutely need to. For a great answer regarding different locking strategies see here.

The database manages concurrent locking and ensures that changes are made atomically. This is a benefit of using a database that supports ACID transactions.

In most cases changes are quick enough that lock contention is minimal. But it can still happen, so you need to check for error status returned after you execute an SQL query. The mysql_query() function returns FALSE if there s a problem.

Then you get to figure out the cause (update conflict, insufficient permissions, SQL syntax error, etc.) by calling mysql_errno(). See http://dev.mysql.com/doc/refman/5.1/en/error-messages-server.html for MySQL error code reference.

I can t believe that none of the above answers are pointing out that you may be running into a design flaw.

Yes all the answers are correct, mysql can handle racing conditions and mutually exclusive access to tables.

However, if you come across a problem like this it is probably time to re-think your design. Why are you not keeping a user id for whoever added a portion of their winnings? You could then have a:

    INSERT INTO team1(userid, amount) VALUES(32, 100);
    SELECT SUM(amount) FROM team1
or
    REPLACE INTO team1 SET amount = $total

But if it was me, I wouldn t even bother. I would simply set_cookie(team_score, team_score+amount) and keep everything client side. When I would want to read the score I would fire an AJAX request to read or write to the server and still update the client interface asynchronously. Since you point out that your web development is basic I recommend that you have a look at the jQuery framework for asynchronous client-server communication as it is by far the easiest way to achieve this.

EDIT: And for the problem of updating everyone s UI when another player adds an amount to the score, I suggest you look into backbone.js which tights your data model nicely to the players client so that they get immediate updates when the score changes.

Databases have built in concurrency control, for example you can read about postgres concurrency control here. If I am right, the default settings by pgsql are optimistic locking and read committed transaction isolation, which means that every transaction is aware of the changes done by other uncommitted transactions.

In you case these settings are okay, so you can do simply UPDATE team1 SET score = score + mytotal, and the database will handle well the concurrency issues.

If you have a longer select - update issue, then you can lock the rows manually by the first select with a SELECT FOR UPDATE query.

These are the best practices currently...