Vertical Partitioning:
There are two types of vertical partitioning, normalization and row split:
Normalization is the standard database process of removing redundant columns from a table and putting them in secondary tables that are linked to the primary table by primary key and foreign key relationships.
Horizontal partitioning:
Horizontal partitioning divides a table into multiple tables. Each table then contains the same number of columns, but fewer rows. For example, a table that contains 1 billion rows could be partitioned horizontally into 12 tables, with each smaller table representing one month of data for a specific year.
Advantages:
Partitioning** in general, results in smaller, manageable data sizes, so indexes are built faster, queries run faster, more data can actually fit into memory, and so on. With Vertical Partitioning, you break a large table, typically with lot of columns, into multiple tables based on certain criteria so as to minimize the need for querying across those multiple tables. So, after the vertical partitioning into 3, a large table with 'n' rows and 'm' columns may look like:
table_partition_1: 'n' rows, 'x' columns
table_partition_2: 'n' rows, 'y' columns
table_partition_3: 'n' rows, 'z' columns
where (x + y + z) = m
With Horizontal Partitioning, you keep the columns in a large table intact, but split the rows, again based on certain criteria so as to minimize querying across multiple partitions. With the above example, a horizontally partitioned table might look like:
table_partition_1: n/k rows, 'm' columns
...
table_partition_k: n/k rows, 'm' columns
Note that above is to illustrate the concept; each partition may (will) not hold the same number of rows.
With Sharding, you throw each partition into a separate database instance for geo-distribution, and other purposes.
So, which scheme is better? One is not necessarily better than other and the choice depends largely on the type of the data, number of rows in the table, the application requirement, global availability, and so on. If some columns are rarely queried (or others are queried pretty often) you could go with vertical partitioning. If the data lends itself to split naturally (such as users in a given location, items shipped to zip codes, and so on), horizontal partitioning is useful. With either approach, cross partition queries should be avoided or at least minimized since doing so would defeat the purpose of partitioning in the first place.
Note that partitioning and sharding are not without their headaches and are suggested only after you have exhausted all other options such as query optimization, caching, read-replication, and so on.
** The difference between Partitioning and Sharding is mostly semantic. With Partitioning, your tables will still be in the same database instance whereas with Sharding, your tables are split across multiple database servers.
src:
http://stackoverflow.com/questions/18302773/what-are-horizontal-and-vertical-partitions-in-database-and-what-is-the-differen
https://technet.microsoft.com/en-us/library/ms178148(v=sql.105).aspx
https://www.quora.com/What-are-the-advantages-of-vertical-and-horizontal-partitioning-of-databases
