Partition (database)

* ”’Horizontal partitioning”’ involves putting different rows into different tables. For example, customers with [[ZIP code]]s less than 50000 are stored in CustomersEast, while customers with ZIP codes greater than or equal to 50000 are stored in CustomersWest. The two partition tables are then CustomersEast and CustomersWest, while a [[View (database)|view]] with a [[Union (SQL)|union]] might be created over both of them to provide a complete view of all customers.

* ”’Horizontal partitioning”’ involves putting different rows into different tables. For example, customers with [[ZIP code]]s less than 50000 are stored in CustomersEast, while customers with ZIP codes greater than or equal to 50000 are stored in CustomersWest. The two partition tables are then CustomersEast and CustomersWest, while a [[View (database)|view]] with a [[Union (SQL)|union]] might be created over both of them to provide a complete view of all customers.

* ”’Vertical partitioning”’ involves creating tables with fewer columns and using additional tables to store the remaining columns.<ref name=”:0″>[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.97.8306 “Vertical Partitioning Algorithms for Database Design”], by Shamkant Navathe, Stefano Ceri, Gio Wiederhold, and Jinglie Dou, Stanford University 1984</ref> Generally, this practice is known as [[Database normalization|normalization]]. However, vertical partitioning extends further and partitions columns even when already normalized. This type of partitioning is also called “row splitting”, since rows get split by their columns, and might be performed explicitly or implicitly. Distinct physical machines might be used to realize vertical partitioning: Storing infrequently used or very wide columns, taking up a significant amount of memory, on a different machine, for example, is a method of vertical partitioning. A common form of vertical partitioning is to split static data from dynamic data, since the former is faster to access than the latter, particularly for a table where the dynamic data is not used as often as the static. Creating a view across the two newly created tables restores the original table with a performance penalty, but accessing the static data alone will show higher performance. A [[columnar database]] can be regarded as a database that has been vertically partitioned until each column is stored in its own table.

* ”’Vertical partitioning”’ involves creating tables with fewer columns and using additional tables to store the remaining columns.<ref name=”:0″>[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.97.8306 “Vertical Partitioning Algorithms for Database Design”], by Shamkant Navathe, Stefano Ceri, Gio Wiederhold, and Jinglie Dou, Stanford University 1984</ref> Generally, this practice is known as [[Database normalization|normalization]]. However, vertical partitioning extends further, and partitions columns even when already normalized. This type of partitioning is also called “row splitting”, since rows get split by their columns, and might be performed explicitly or implicitly. Distinct physical machines might be used to realize vertical partitioning: storing infrequently used or very wide columns, taking up a significant amount of memory, on a different machine, for example, is a method of vertical partitioning. A common form of vertical partitioning is to split static data from dynamic data, since the former is faster to access than the latter, particularly for a table where the dynamic data is not used as often as the static. Creating a view across the two newly created tables restores the original table with a performance penalty, but accessing the static data alone will show higher performance. A [[columnar database]] can be regarded as a database that has been vertically partitioned until each column is stored in its own table.

==See also==

==See also==