Question: (**Note** that this situation isn't exactly how it is, but I made this as an example)

I have an entity in a table with data that is updated every 5 seconds (**Kinematic Data**: Speed, Heading, Lat, Long, and PositionTime), and other data that is updated hardly at all, if ever (Color, Make, OriginTime).

[alt text http://www.freeimagehosting.net/uploads/a67205e99e.jpg](http://www.freeimagehosting.net/uploads/a67205e99e.jpg)

Now my boss wants me to partition this data into separate tables in our database (With a One to One Relationship), as so:

[alt text http://www.freeimagehosting.net/uploads/1c699bc3c5.jpg](http://www.freeimagehosting.net/uploads/1c699bc3c5.jpg)

He makes it sound "obvious" that it should be this way, but is there really any advantages to having this data separated as so for inserting and updating (For instance if I put an index on Color or Make)?

Answer: 
It might make sense to do vertical partitioning like this. Or it might not.

When you use a MVCC based engine, each time you update a row, it generally\* copies the entire row and creates a new one with the modifications. This is so that other transactions which do not yet see the update can continue to read the original row if they need to.

This means that updating a few small columns frequently in a very wide row causes the database to do a lot more writes than it needs to.

But not that many, because generally the engine will only sync its transaction log, which will be the same size regardless of the size of non-updated columns, and also because the data rows are usually stored in blocks where a whole block needs to be written anyway, regardless of how much of it changed.

So it sounds like a potentially pointless optimisation, which like any other, should be considered on the grounds of
a) IS there really a performance problem (i.e. is ANY optimisation needed) and
b) Is this particular optimisation the best way of fixing it?

I think the chance of a) is unlikely, and b) is also unlikely, so the chances of this being required is approximately unlikely-squared.

\* Some engines make an exception for very large columns such as big BLOBs or text columns, which are held elsewhere and not copied if other columns in the row are updated.
If the point of this design is to maintain a *history* of the kinematic data then the design makes sense. Although there doesn't seem to be a key in the `CAR_KINEMATIC` table which fits that usage. If on the other there is a one-to-one relationship between these two tables the division is meritless.