Overall, is it better to store the raw data for the state of a "game" or the websocket events that lead up to that point?

I'm currently planning out a webapp which would involve 2 users being able to join a room and play a tabletop game versus each other. I would be using some kind of Javascript framework on the front end, Socket.IO and Express.js/MySQL backend.

Users would be able to "place" pieces on a board, such as in particular locations, and I obviously somehow need that data to be stored (e.g. Location 1 on the board is occupied by X piece, Location 2 is occupied by Y piece).

When a user does an action to move a piece from Location 1 to Location 2, I would like to transmit a websocket saying "Piece X moved from Location 1 to 2". Afterwards update clients with this information.

Adding to this, I would like users to be able to join and spectate other games inbetween. And this is primarily what makes me ask my question: To store the current "state" of the player pieces (and the game in general), is it better to literally store them in a MySQL table with columns for each piece of data such as locations on the board? This means when a spectator joins, the board can be populated by reading the table, however this means there will be no "history" available. Or would it be better to store every websocket event that has been emitted, in a table, and then when somebody joins simply loop through them and re-emit them for that particular client - thus catching them up with history?

By "better" I mean - which method would be the fastest and most efficient? Which would have less strain on the database? Which just overall makes more sense from a programming perspective?

via uuu