The scheme of storing the changing data history

There are about 300 thousand of objects ( e.g. cars) for each car once a week is measurement parameters ( mileage, tire pressure, fuel quantity), the parameters will be around 20 pieces, we need to store in the database.

In osnovnom users will be interested in only the last settings. But sometimes you need to answer questions like "how has varied the tire pressure in time," "And what parameters have been changed last week"

Instinct says probably need to look in the direction of mongo, but the assignment clearly said that will use Mysql :)

Have been born two choices

1)

The first table (called data)

id| object_name | param1 | param1_is_changed | param1_change_date | param2...

The second table (the name data_history)

id| object_name | param1 | param1_is_changed | param1_change_date | param2... | version | change_date

Each time any parameter is changed, the previous version is saved in data_history, the parameter which is changed is vlarok is_changed

2) the First table (called data)

id| object_name

The second table ( stores only the last value)

id | object_id | param_name | param_value | date

The third table ( keeps track of values from second table)


Now we are tracking about 50 thousand objects, in a week there are about 200 changes in the parameters. All parameters are numeric, so the question is redundant storage in the first case, only care about performance in the database, but not disk space. The second method seems good, but it is not very easy to implement using ORM.

Your opinion? how to design the DB? how to find an effective compromise between the database and the ease of writing applications to it.