Diseño y rendimiento de bases de datos (SQL Server Compact Edition)
Puede mejorar notablemente el rendimiento de la aplicación SQL Server 2005 Compact Edition (SQL Server Compact Edition) 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, sólo 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 sólo algunas columnas de claves se denomina un índice estrecho. Un índice con varias columnas de claves 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 términos de tamaño de base de datos como en rendimiento de las consultas.
Tipos y opciones de artículos de publicación
Al crear una publicación en SQL Server 2000, se crea una publicación con artículos estándar. Si se filtran, estos artículos utilizan el filtrado normal. Sin embargo, si crea una publicación en SQL Server 2005, puede elegir entre dos opciones adicionales para los artículos de la publicación. Estas opciones, que controlan el filtrado y el flujo de datos entre el publicador y el suscriptor, son las siguientes:
- Sólo descarga (sólo lectura)
Pueden producirse situaciones en las que los datos que desea tener en el dispositivo inteligente sólo estén almacenados en tablas de búsqueda. Por ejemplo, los usuarios pueden examinar el directorio de la compañía en sus dispositivos inteligentes, pero no podrán editar ni cambiar la información. El tipo de artículo Sólo descarga está pensado para estas situaciones. Es más pequeño porque no se almacenan metadatos en el dispositivo y reduce el tráfico de red durante la sincronización. - Particiones eficaces
Aunque con SQL Server 2000 puede crear grupos de particiones, esto puede repercutir negativamente en el rendimiento durante las cargas de datos, ya que las asignaciones de Id. de las particiones deben calcularse con cada carga. Con los artículos divididos en particiones eficaces de SQL Server 2005, los cambios que se cargan se asignan únicamente a un solo id. de partición. Esto es mucho más rápido, pero presenta varias limitaciones:- Cada fila del artículo debe pertenecer sólo a un Id. de partición.
- Cada artículo solamente se puede publicar en una sola publicación.
- El suscriptor no puede insertar filas que no pertenezcan a su Id. de partición.
- El rendimiento del filtrado también se ve afectado cuando se utilizan artículos divididos en particiones eficaces. El filtrado está expuesto a las siguientes limitaciones:
- Un suscriptor no puede actualizar las columnas que intervienen en el filtrado.
- En una jerarquía de filtros de combinación, un artículo normal no puede ser el primario de un artículo dividido en particiones eficaces.
- El filtro de combinación en el que un artículo dividido en particiones eficaces es secundario debe tener el valor join_unique_key establecido en 1.
- Cada artículo sólo puede tener un filtro de subconjunto o combinación. El artículo puede tener un filtro de subconjunto y ser el primario de un filtro de combinación, pero no puede tener un filtro de subconjunto y ser el secundario de un filtro de combinación.
Vea también
Conceptos
Ajuste del rendimiento de las consultas (SQL Server Compact Edition)
Otros recursos
Mejorar el rendimiento (SQL Server Compact Edition)