Diseño y rendimiento de bases de datos (SQL Server Compact)
Puede mejorar notablemente el rendimiento de la aplicación SQL Server Compact 4.0 si diseña correctamente la publicación y la base de datos de SQL Server. En las siguientes secciones se describen las técnicas que pueden aplicarse para mejorar el rendimiento.
Utilizar la desnormalización de la base de datos
Una base de datos normalizada impide las dependencias funcionales de los datos para que el proceso de actualización de la base de datos sea fácil y eficiente. Sin embargo, la realización de consultas en la base de datos puede requerir la combinación de varias tablas para unir la información. A medida que el número de tablas combinadas crece, el tiempo de ejecución de la consulta aumenta considerablemente. Por este motivo, el uso de una base de datos normalizada no es siempre la mejor alternativa. Una base de datos con la medida justa de desnormalización reduce el número de tablas que deben combinarse sin dificultar en exceso el proceso de actualización. Suele ser la solución más acertada.
Nota
Por lo general, si un número importante de las consultas precisan de la combinación de más de cinco o seis tablas, es aconsejable el uso de la desnormalización.
Existen además dos tipos de desnormalización de base de datos. Por ejemplo, supongamos que en una base de datos hay dos tablas: Orders y Order Details. La tabla Orders contiene información acerca del pedido de un cliente. Los productos individuales de cada pedido están incluidos en la tabla Order Details. Supongamos que desea consultar el importe total en dólares de cada pedido. En primer lugar, debe determinar el importe en dólares de cada producto (unidades * precio por unidad – descuento aplicable). A continuación, debe agrupar los importes por pedido. La consulta tendrá más o menos este aspecto:
SELECT "Order ID", SUM("Unit Price" * Quantity * (1.0 - Discount))
AS Total FROM "Order Details"
GROUP BY "Order ID"
Order ID Total
----------------------------------------
10000 108
10001 1363.15000915527
10002 731.800003051758
10003 498.180023193359
10004 3194.19999694824
10005 173.400009155273
10006 87.2000007629395
10007 1405
10008 1171
10009 1530
10010 470
... ...
(1078 rows affected)
El cálculo de esta consulta no es fácil. La consulta puede tardar bastante tiempo en ejecutarse si existen muchos pedidos. La alternativa consiste en calcular el importe en dólares del pedido en el momento de realizarse y, después, guardar el importe en una columna de la tabla Orders. De este modo, solo debe consultar la columna precalculada para obtener la información que necesita:
SELECT "Order ID", "Order Total" AS Total FROM Orders
La creación de una columna precalculada permite ahorrar mucho tiempo en consultas, aunque este método implica mantener una columna adicional en la tabla.
Columnas de longitud fija o variable
El diseño de las tablas le permite comprender las ventajas e inconvenientes del uso de columnas de longitud fija y de longitud variable. Las columnas de longitud variable reducen el tamaño de la base de datos porque solamente ocupan el espacio necesario para almacenar el valor real. Las columnas de longitud fija siempre ocupan el espacio máximo definido por el esquema, aunque el valor real esté vacío. El inconveniente de las columnas de longitud variable radica en que algunas operaciones no son igual de eficaces que en las columnas de longitud fija. Por ejemplo, si una columna de longitud variable es inicialmente pequeña y crece considerablemente después de una actualización, es posible que el registro deba reubicarse. Además, si se realizan actualizaciones con frecuencia, las páginas de datos se fragmentan más con el paso del tiempo. Por lo tanto, es recomendable el uso de las columnas de longitud fija cuando la longitud de los datos no varía demasiado y cuando se realizan actualizaciones con frecuencia.
Crear longitudes de fila menores
El número de filas que una página puede contener del tamaño de cada fila. Una página podrá contener más filas si éstas son pequeñas. Así pues, una sola operación de disco realizada en una tabla con filas compactas recuperará más filas y, de este modo, la operación será más efectiva. Asimismo, la caché del motor de almacenamiento tiene capacidad para más filas, lo que permite aumentar potencialmente la tasa de visitas. Las filas compactas también contribuyen a reducir el espacio desaprovechado en las páginas de datos. Esto es más característico de las filas grandes.
Tomemos como ejemplo la improbable situación siguiente: si el tamaño de un registro es algo mayor que la mitad de una página de datos, se pierde casi la mitad del espacio en cada página. Algunos diseñadores de bases de datos optan por un diseño de tabla ancho y trasladan el esquema de la base de datos para grandes sistemas (mainframe) al dispositivo. Es probable que este diseño no sea eficiente. Una posible solución consiste en dividir las tablas más importantes. Supongamos que algunas columnas de una tabla cuentan con valores muy estables y otros que cambian con frecuencia. Parecería lógico dividir la tabla en dos: una con las columnas a las que se hace referencia a menudo y otra con las columnas más estables. La creación de dos tablas ofrece todas las ventajas de utilizar filas de longitud menor. El único inconveniente es que es necesario realizar una combinación para unir la información.
Utilizar longitudes de clave menores
Un índice es un subconjunto ordenado de la tabla en la que se ha creado. Permite realizar las búsquedas de intervalos y los criterios de ordenación con mayor rapidez. Las claves de índice más pequeñas ocupan menos espacio y son más efectivas que las claves más grandes. Por lo general, es aconsejable que la clave principal sea compacta porque se suele hacer referencia a ella a menudo como una clave externa en otras tablas. Si originalmente no existe una clave principal compacta, puede utilizar una columna de identidad implementada como un entero.
Un índice con una o solo algunas columnas de clave se denomina un índice estrecho. Un índice con varias columnas de clave se denomina un índice ancho. Los índices anchos suelen estar asociados con las longitudes de clave grandes. Un ejemplo improbable sería el de un índice que incluye cada columna de la tabla. Al crear este tipo de índice, está en realidad creando un duplicado de la tabla original, lo que es ineficiente, tanto en lo que respecta al tamaño de las bases de datos como al rendimiento de las consultas.
Vea también
Conceptos
Ajuste del rendimiento de las consultas (SQL Server Compact)