History log on Ticket system database
I'd say that as long as you can guarantee that you (or anyone else) won't change the definitions of the '3','5','6','2' values somewhere down the road, it's not a bad idea.

You'll end up having to do a little more work with the first option to get it into a "User-friendly" view (if that's your end goal), but it seems like INT values (old_value, new_value) would be easier to store than full text values (message).  The main advantage to your second option is that it's easier to read and you don't have to link a few tables together to get the user-friendly version.

Another way I've seen it done (Particularly by Salesforce) is to select which fields you'd like tracked in an object.  Say "status" and "assistant" are your choices.  Salesforce will have a structure as follows:

id | ModifiedDate | OldValues                     | New Values
1  | 08/26/2016   | Status: Open, Assistant: John | Status: Closed, Assistant: Kyle


This is if at least one value changed.  So even if the assistant hadn't changed, it still displays all field values.

  id | ModifiedDate | OldValues                     | New Values
  1  | 08/26/2016   | Status: Open, Assistant: John | Status: Open, Assistant: Kyle


It also tracks initial "inserts" as such:

id | ModifiedDate | OldValues             | New Values
1  | 08/26/2016   | Status: , Assistant:  | Status: Open, Assistant: John


Hope that helps a bit.