The database systems most of us are familiar with are row oriented. A row typically holds all the details associated with a particular entity (customer, employee, product etc) and so it is is natural to use this regime when dealing with transactional data. In terms of actual storage on the disk, all the attributes for an entity are stored together since in a transactional environment they are usually needed as a whole unit.
When it comes to using data for analysis and reporting the situation changes. We are very often interested in totals, filtering and other actions that might relate to a single attribute. For example we might be interested in all customers who spent more than $500 last year. A column oriented database is ideal for this since it becomes possible to read all the last_year values in a couple of database reads – this column is stored in one location, instead of spread throughout the whole database in the case of a row oriented database.
Whether a row or column oriented database is used depends purely on the tasks it needs to execute.
Database technology with support for column orientation includes: