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: 
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.
Your boss is right. And this has nothing to do with "partitioning", its called normalization.

[Read this article.](http://en.wikipedia.org/wiki/Database_normalization)

**EDIT**: Ok, "vertical partitioning" is a well-known term, and normalization is one method of vertical partitioning. But in this case, normalization seems to be the right answer, which **explains** the question (Quote: "... is there really any advantages to having this data separated as so for inserting and updating"). Advantages and disadvantages of normalization are very well-known. The wikipedia article is a good starting point.

And BTW, to keep the flames of "Erwin Smout" burning: "vertical decomposition" does not seem to be a commonly used term here. Right?