Las operaciones más costosas que involucran a los discos duros son las búsquedas.
Para mejorar el rendimiento global, los datos relacionados deberían ser almacenados en una forma que minimice el número de búsquedas.
En este caso los registros tienen rowids secuenciales independientes del empid asignado al usuario.
Por ejemplo, para encontrar todos los registros en la tabla del ejemplo con salarios entre 40,000 y 50,000, el SGBD tendría que escanear completamente toda la tabla en busca de registros que cumplan ese criterio.
[2] Esto puede parecer sutil, pero la diferencia puede ser vista en esta modificación común al mismo almacén donde los dos elementos "Jones" son comprimidos en un solo elemento con dos rowids: Si un sistema orientado a columnas será más eficaz, o no, en la operación depende en gran medida de la carga de trabajo a ser automatizada.
Las operaciones que recuperan todos los datos para un objeto dado (la fila entera) son más lentas.
Aun así, estas operaciones de fila entera son generalmente raras.
En una aplicación rolodex, por ejemplo, recuperar el nombre y apellido de muchas filas para construir una lista de contactos es mucho más común que leer todos los datos para una única dirección.
[3] El particionamiento, la indexación, el cacheo, las vistas, los cubos OLAP, y los sistemas transaccionales tales como "write-ahead logging" o el control de concurrencia mediante versiones múltiples, todo esto afecta dramáticamente la organización física de cualquier sistema.
Por ejemplo, un típico disco duro Serial ATA (SATA) tiene un tiempo de búsqueda promedio de entre 16 y 22 milisegundos, mientras que el acceso DRAM en un procesador Intel Core i7 toma en promedio 60 nanosegundos, casi 400,000 veces más rápido.
Las transacciones (INSERT's) tienen que ser separadas en columnas y comprimidas cuando son almacenadas, haciéndolas menos convenientes para cargas de trabajo OLTP.
Por ejemplo, la recuperación de todos los datos de una única fila es más eficiente cuando esos datos están localizados en una única ubicación (minimizando búsquedas en disco), como lo es en arquitecturas orientadas a filas.
Sin embargo, los sistemas orientados a columnas han sido desarrollados como híbridos capaces de ambas operaciones, OLTP y OLAP.
[8] Aunque estas mismas técnicas pueden ser utilizadas en datos orientados a filas, en una implementación típica se alcanzarán resultados menos efectivos.
[12] Por ejemplo, dada una tabla con columnas sexo, edad, nombre, sería mejor ordenar primero respecto al valor sexo (cardinalidad de dos), luego por edad (cardinalidad <150), y luego por nombre.