UDP is okay, you have exactly the same problems as you would have on a LAN but with the bonus that you can do NAT Hole punching

TCP/IP is easier to use (no packet losses and everything comes in the expected order) so go with that if you think it is easier for you.

For the "how does it work", it is a correct start but you seems to have forgotten the "server" or some of its work namely to act as a buffer between the database and the client:

Client negotiates a login (server checks database for login, pass, playerID etc) Server loads up the new player from database to memory and sends That off to the client.

Every change will primarily affect the memory (I use a class Player that holds all the data of a character for example) and only rarely the server will save off the memory to the database (for example, the minimum required is when a player quits the game).

I use the same technique for items, they get checked out too by the server and 'saved' in the player class. Every time the player changes owner (I give you an apple) I reflect that instantly and then I save off the new state to the database, this way it is fast and secure and fast(I can send back information before even touching the database).

Another thing is of course the need to add another 'layer' for lag compensating. This doesn't need to be something extremely complicated but some data (like positions) should not be updated directly when the client gets information from the server but saved off in another variable and the client position can then use some sort of lag compensation like interpolation or dead reckoning

Good luck and as a side note, what's the game about?

UDP is okay, you have exactly the same problems as you would have on a LAN but with the bonus that you can do NAT Hole punching

TCP/IP is easier to use (no packet losses and everything comes in the expected order) so go with that if you think it is easier for you.

For the "how does it work", it is a correct start but you seems to have forgotten the "server" or some of its work namely to act as a buffer between the database and the client:

Client negotiates a login (server checks database for login, pass, playerID etc) Server loads up the new player from database to memory and sends That off to the client.

Every change will primarily affect the memory (I use a class Player that holds all the data of a character for example) and only rarely the server will save off the memory to the database (for example, the minimum required is when a player quits the game).

I use the same technique for items, they get checked out too by the server and 'saved' in the player class. Every time the item changes owner (I give you an apple) I reflect that instantly and then I save off the new state to the database, this way it is fast and secure and fast(I can send back information before even touching the database).

Another thing is of course the need to add another 'layer' for lag compensating. This doesn't need to be something extremely complicated but some data (like positions) should not be updated directly when the client gets information from the server but saved off in another variable and the client position can then use some sort of lag compensation like interpolation or dead reckoning

Good luck and as a side note, what's the game about?