Tho's e-mail:
I read quickly about MySQL stored procedures and functions. I had in mind the following: to avoid inconsistency, have the server send work to the DB, rather than pulling data and suffer race conditions, etc. And that also makes the game server layer "thinner" (ie the server loses logic). I think making the server thinner has pros (stronger consistency) and cons (logic spread around, so harder to debug). I think it may be worth a try for small and simple tasks (think atomic operations where inputs and outputs can be written on a truth table).
en.wikipedia.org/wiki/Stored_procedure
1- SQL functions are a first step to embed game logic closer to the data. The perfect example is inflicting dmg: if I send a bomb at x,y, inflict dmg to all entities located there, and return a table where rows = entities, columns = dmgInflicted + isDead. The game server reformats the table for the client msg. In the end, you have saved 1 round-trip server-DB, and get stronger consistency because the work was executed where the data was.
2- A second (more advanced?) step could be stored procedures. I got a book about it. Looking at page 3's simplest examples, you can run a bunch of statements per procedure. I see it as a big round-trip saver, although super hard to debug. I'm not sure how much more we could get from stored proc compared to functions.
On a side note, I read somewhere that prepared statements increased perf by 20%.
Tho's e-mail: I read quickly about MySQL stored procedures and functions. I had in mind the following: to avoid inconsistency, have the server send work to the DB, rather than pulling data and suffer race conditions, etc. And that also makes the game server layer "thinner" (ie the server loses logic). I think making the server thinner has pros (stronger consistency) and cons (logic spread around, so harder to debug). I think it may be worth a try for small and simple tasks (think atomic operations where inputs and outputs can be written on a truth table). en.wikipedia.org/wiki/Stored_procedure 1- SQL functions are a first step to embed game logic closer to the data. The perfect example is inflicting dmg: if I send a bomb at x,y, inflict dmg to all entities located there, and return a table where rows = entities, columns = dmgInflicted + isDead. The game server reformats the table for the client msg. In the end, you have saved 1 round-trip server-DB, and get stronger consistency because the work was executed where the data was. 2- A second (more advanced?) step could be stored procedures. I got a book about it. Looking at page 3's simplest examples, you can run a bunch of statements per procedure. I see it as a big round-trip saver, although super hard to debug. I'm not sure how much more we could get from stored proc compared to functions.
On a side note, I read somewhere that prepared statements increased perf by 20%.