¿Le resultó útil esta página?
Sus comentarios sobre este contenido son muy importantes. Háganos saber su opinión.
¿Tiene comentarios adicionales?
Caracteres restantes: 1500
Arquitectura de almacenamiento de datos con SQL Server 2005 Compact Edition

Arquitectura de almacenamiento de datos con SQL Server 2005 Compact Edition

SQL Server 2005

Marzo de 2007

Publicado: 2 de Abril de 2007

Brian Noyes
IDesign, Inc.

Revisores técnicos
Sitaram Raju, Sachin Sinha
Microsoft Corp.

Se aplica a:
   SQL Server 2005 Compact Edition
   Arquitectura de almacenamiento de datos

Resumen: SQL Server 2005 Compact Edition (SSCE) ofrece un motor eficaz pero a la vez ligero de almacenamiento de datos para crear distintos de tipos de aplicación. En este artículo se presentan cuestiones de almacenamiento de datos para aplicaciones cliente y aplicaciones de servidor a pequeña escala. Se describe el conjunto de características de SSCE y cómo este conjunto de características trata las cuestiones de almacenamiento de datos. Se tratan las distintas arquitecturas de aplicaciones donde SSCE puede ser una elección adecuada, resaltando los atributos de los tipos de aplicación y cómo SSCE se puede adaptar a las necesidades de cada tipo de aplicación.

Haga clic aquí para descargar una versión de este artículo en documento Word, DataArchSSCE.doc.

En esta página

 Introducción
 Desafíos del almacenamiento de datos
 Información general sobre el almacenamiento de datos
 Aplicaciones de almacenamiento de datos
 Opciones de almacenamiento de datos
 Información general sobre SQL Server 2005 Compact Edition
 Diseño de soluciones con SSCE
 Conclusión

Introducción

La selección de la arquitectura de almacenamiento de datos adecuada para sus aplicaciones puede ser una tarea complicada. El número de tecnologías de almacenamiento de datos es muy elevado y no para de crecer. La tecnología de almacenamiento de datos que el usuario selecciona depende de varios factores. Es necesario analizar los elementos de compensación entre los requisitos de plataforma, el tamaño, el rendimiento, la facilidad de implementación, la facilidad de acceso a datos y las capacidades de almacenamiento de datos.

Para aplicaciones de servidor que atienden a muchos usuarios, la elección es clara: use SQL Server  2005. La edición basada en servidor de SQL Server  2005 que use depende de la escala y el centro de su aplicación pero la lista de características facilita bastante la labor de decidir qué versión es la que se necesita. Además, el cambio de versión es una decisión sencilla que únicamente afecta a las licencias y, generalmente, no requiere ningún cambio en la arquitectura.

Para aplicaciones cliente o aplicaciones de servidor a pequeña escala, la selección de una tecnología de almacenamiento de datos es un poco más complicado. Para aplicaciones cliente, no tiene sentido poner una instancia completa de escala de SQL Server 2005 en cada equipo cliente por el costo, la complejidad y los requisitos de plataforma que conlleva, además de por otros factores. Para aplicaciones de servidor a pequeña escala, la potencia adicional de SQL Server 2005 quizás no sea necesaria, y el costo en concepto de licencias puede ser prohibitivo para proyectos pequeños. Para aplicaciones de dispositivo móvil, la plataforma no admite una versión completa de SQL Server.

En estas notas del producto se comentan los desafíos, los escenarios y las soluciones de la arquitectura de almacenamiento de datos con el nuevo SQL Server 2005 Compact Edition (SSCE). Se tratan las similitudes y las diferencias entre SSCE, otras ediciones de SQL Server 2005 y otras tecnologías de base de datos relacional, incluido el motor de base de datos incrustado EDB en dispositivos móviles.

Desafíos del almacenamiento de datos

Para una aplicación cliente o aplicaciones de servidor a pequeña escala, es necesario resolver algunas dificultades de almacenamiento de datos:

  • Ubicación del almacenamiento de datos. Si crea una aplicación cliente distribuida y puede proporcionar almacenamiento para sus datos en un servidor back-end y recuperar los datos a través de la red, solamente puede usar SQL Server 2005 en el servidor. Si crea un dispositivo móvil o una aplicación cliente, probablemente necesite un almacén de datos local en el cliente para almacenar en la memoria caché los datos cuando esté desconectado. Es posible que también necesite realizar operaciones de almacenamiento en la memoria caché del cliente para evitar tener que recuperar varias veces y a través de la red conjuntos de datos de gran volumen, como catálogos de productos. Para aplicaciones cliente, es posible que sólo necesite los datos de forma local, en cuyo caso, el almacenamiento en un servidor back-end no tiene ningún sentido.

  • Facilidad de acceso a datos. La productividad es un factor muy importante a la hora de comercializar aplicaciones en el momento adecuado y dentro del presupuesto. La tecnología de almacenamiento de datos debe hacer que leer y escribir datos desde su ubicación de almacenamiento sea muy fácil.

  • Facilidad de consulta. Una tecnología de almacenamiento de datos estable permite buscar fácilmente y seleccionar registros o recopilaciones individuales de registros, y además, hacerlo con rapidez.

  • Capacidad de sincronizar almacenes de datos. Para aplicaciones cliente móviles, los datos sin conexión almacenados deben ser sincronizados de forma local con almacenes de datos de servidor. Escribir mecanismos de sincronización desde cero puede llevar a errores y es muy lento. La tecnología del almacenamiento de datos debe admitir la sincronización de múltiples almacenes de datos.

  • Seguridad. Especialmente en el caso de dispositivos móviles o equipos cliente portátiles, la seguridad es muy importante en lo que se refiere a proteger los datos cuando se almacenan, de forma que, si se roba el equipo, ningún usuario no autorizado pueda obtener acceso a los datos. Además, al sincronizar los datos, debe existir protección para los datos en tránsito.

  • Integridad de los datos. Cuando lee y escribe datos de su almacén, debe estar seguro de que los datos se almacenan de forma coherente y de que los datos no resultan dañados. Los almacenes de datos de transacción ofrecen mecanismos para garantizar esta coherencia, y deben tener prioridad sobre los almacenes de datos sin transacción.

  • Facilidad de implementación. Para aplicaciones cliente, un impacto leve y una instalación sencilla son elementos imprescindibles para obtener compatibilidad y mantenimiento. La configuración necesaria en la aplicación cliente debe ser minimizada para asociar la aplicación al almacén de datos.

Información general sobre el almacenamiento de datos

Existe una serie de opciones disponibles para el almacenamiento de datos. No hace mucho tiempo, muchas aplicaciones serializaban datos en formatos de titularidad ajena para archivos sin formato del disco. El estándar XML ofrece una manera más estructurada y fácil de usar para almacenar datos arbitrarios en archivos pero no resuelve muchas de los desafíos descritos en la sección anterior. Las tecnologías de base de datos relacional es, en realidad, la única opción con una amplia disponibilidad que permite el almacenamiento de datos para resolver absolutamente todas las dificultades necesarias para obtener un almacenamiento de datos sólido.

Incluso una vez que ha fijado su atención en las tecnologías de base de datos, existen varias opciones disponibles. Es neceario usar otros criterios para seleccionar la tecnología apropiada y seleccionar la tecnología de base de datos correcta basada en el modo en que cada opción trata los desafíos descritos en la sección anterior. Además, debe decidir si la base de datos se usará como una base de datos de cliente para un solo usuario o una base de datos de servidor para varios usuarios.

En aplicaciones cliente, debe centrarse en una de dos opciones, según si es una aplicación de escritorio o una aplicación de dispositivo móvil. Para aplicaciones de escritorio (que se ejecutan en una estación de trabajo de escritorio, en el equipo portátil o en un Tablet PC), céntrese en SQL Server 2005 Compact Edition (SSCE) o SQL Server 2005 Express Edition (SSE). Para dispositivos móviles que se ejecutan en Microsoft Windows CE o sistemas operativos Mobile, puede elegir entre SSCE o el motor de base de datos incrustado EDB.

Por varios motivos, que se tratan en más detalle más adelante en estas notas del producto, SSCE ofrece una solución fantástica y fácil de usar para la mayoría de aplicaciones de negocio cliente. SSE sólo es necesario para aplicaciones cliente especializadas, pero es una buena elección para aplicaciones de servidor a pequeña escala que admiten la carga de usuario moderada precisan una arquitectura más sólida y escalable. EDB puede ser una buena elección si necesita compatibilidad nativa con el dispositivo y se preocupa por la repercusión en el disco y la memoria de instalar SSCE en el dispositivo, pero tendrá que sopesar esto junto con la mayor productividad y las características que ofrece SSCE.

Para aplicaciones de servidor a pequeña escala y necesidades de almacenamiento en caché, SSCE o SSE pueden ser apropiados. Para una aplicación web que tiene alguna posibilidad de crecer y ajustarse a escala en el futuro, SSE es una opción mejor, ya que admite una mayor variedad de capacidades en comparación con SSCE.

Aplicaciones de almacenamiento de datos

Las aplicaciones pueden tener muchas formas y tamaños. Tal como se ha indicado, las aplicaciones de servidor a gran escala en realidad necesitan las ediciones SQL Server 2005 Workgroup, Standard o Enterprise y esta cuestión no es el objeto de estas notas del producto. Para aplicaciones cliente y aplicaciones de servidor a pequeña escala, puede clasificar las aplicaciones en varios tipos de aplicación. Estos tipos son:

  • Aplicaciones de fuerza de campo. Se trata de las aplicaciones cliente que usan los trabajadores móviles en el trabajo. Estas aplicaciones se usan, generalmente, en equipos o Tablet PC, pero también se pueden usar en dispositivos móviles. Permiten presentar datos interactivamente e interactuar para trabajar con clientes o equipos distribuidos.

  • Aplicaciones de administración de información de personal (PIM). Estas aplicaciones cliente se usan para almacenar y tener acceso a recopilaciones de elementos de información, como contactos, programaciones, tareas, notas, etcétera. Se pueden usar en equipos de escritorio, en equipos portátiles o en dispositivos de cliente móvil, pero cada vez más se están desarrollando estos tipos de aplicaciones para la instalación de impacto leve en dispositivos móviles.

  • Aplicaciones web a pequeña escala. Se trata de aplicaciones cliente sencillas de presencia en Internet para presentar información dinámica en Internet a un grupo de usuarios reducido. Como ejemplos podemos encontrar compañías pequeñas, comunidades y organizaciones no lucrativas o clubes. Éstos requieren que se exponga un servidor web, pero que se pueda ejecutar desde un sistema operativo de escritorio como Windows Vista o Windows XP Professional.

  • Aplicaciones de almacenamiento en caché. Tanto si una aplicación cliente está diseñada para funcionar sin conexión como si no, generalmente, no tiene sentido hacer un viaje completo a la base de datos cada vez que se necesita obtener información de búsqueda, como la ciudad, el estado, el código postal, las listas del catálogo del producto, etc. Implementar una memoria caché de datos de cliente puede ofrecer mejoras considerables de rendimiento para la presentación de listas o realizar búsquedas en tablas de búsqueda que cambian con poca frecuencia. Además, algunas aplicaciones pueden estar diseñadas con una arquitectura distribuida que implica aplicaciones cliente inteligente, de dispositivo móvil o de cliente web que se comunican con un servidor de aplicaciones back-end centralizado. El servidor de aplicaciones puede precisar almacenar los datos en caché para evitar viajes de ida y vuelta al servidor de la base de datos. La necesidad de almacenar los datos en la memoria caché de la máquina local no justifica la compra ni la sobrecarga que comparta instalar una instancia completa de SQL Server de forma local en el servidor de aplicaciones.

Opciones de almacenamiento de datos

Para tomar decisiones adecuadas sobre la arquitectura, aborde la solución objetivamente e intente comprender bien en qué consisten las opciones disponibles. Para las necesidades de almacenamiento de datos de su arquitectura, existen varias opciones que examinar. De nuevo, este artículo se centra en el almacenamiento de datos de servidores cliente y servidores a pequeña escala. Para estas partes de la arquitectura, las opciones principales son el almacenamiento de archivo, EDB, SSCE y SSE. Para realizar la selección correcta, debe examinar las capacidades y las limitaciones de cada elección y valorarlos en relación con sus necesidades.

Archivos sin formato o XML

Usar archivos sin formato o XML puede parecer interesante en principio desde el punto de vista de la simplicidad: la mayoría de programadores ya saben cómo usar Microsoft .NET o la serialización XML para leer y escribir datos de archivos, o pueden usar las capacidades de un conjunto de datos para leerlo y escribirlo como código XML de un archivo. Sin embargo, los archivos tienen problemas en cuanto a coherencia y confiabilidad. Si se interrumpe o se cierra una aplicación sin completar apropiadamente las operaciones de E/S ni el cierre del archivo, los datos contenidos pueden dañarse y el bloqueo del archivo puede impedir que la aplicación funcione correctamente. Estos problemas se pueden resolver a través de la administración disciplinada de códigos y errores, pero para lograrlo, se pierde la ventaja que suponía la simplicidad que inicialmente hacía que los archivos fuesen tan prácticos.

Tampoco existe una capacidad inherente para consultar archivos y, generalmente, el usuario debe leer todo el archivo o la mayor parte de éste en estructuras de datos de memoria para que se puedan usar los datos. En consecuencia, los archivos sin formato y XML no son apropiados para los datos que se consultarán, leerán y escribirán a través de la ejecución de la aplicación. Para datos sencillos, como los valores y las preferencias de configuración, los archivos de configuración XML son apropiados. También es preferible almacenar documentos y archivos grandes como archivos sin formato con metadatos en la base de datos, en función de los patrones de acceso. Pero la mayor parte de los datos aleatorios de lectura/escritura de acceso para las aplicaciones debe almacenarse y obtenerse acceso a éstos a través de un motor de base de datos.

EDB

El motor de base de datos incrustado EDB es una parte nativa de los sistemas operativos Windows CE 5.x, 6.x y Mobile 6.x. EDB es un motor de datos relacional sencillo que permite almacenar los datos en tablas con un sistema de tipo limitado y capacidades de consulta limitadas. EDB es una opción interesante si se desea una capacidad nativa en un dispositivo o que se pueda instalar con un impacto y una sobrecarga mínimos en el dispositivo. EDB puede ser más rápido que SSCE para ciertas clases de recuperación de datos sencilla, pero también puede ser más lento si se precisan operaciones de consulta complejas. Una de las desventajas más importantes de usar EDB es que sólo se tiene acceso a éste con una API de bajo nivel en Microsoft Visual C++. Si escribe la aplicación con .NET Compact Framework para comprender las ventajas de productividad asociadas al desarrollo de código administrado, debe escribir un componente de acceso a datos separado que funcione con la base de datos de EDB con C++ y, a continuación, debe usar ese componente desde el código administrado. La complejidad que conlleva esta operación, probablemente supera las ventajas de usar EDB. Solamente se recomienda usar EDB si ya escribe la aplicación con C++ incrustado y desea minimizar el impacto y maximizar el rendimiento de la aplicación.

SQL Server 2005 Compact Edition (SSCE)

SSCE es un motor de base de datos relacional ligero (< 2 MB) que se puede instalar en cualquier sistema operativo Windows actual. Puesto que SSCE es el tema principal de estas notas del producto, el conjunto de características completo se describe en una sección posterior. En un nivel alto, SSCE admite tablas, relaciones, restricciones, procesamiento de consultas complejas, transacciones, réplicas y seguridad de los datos. Para programar con SSCE, se usa un proveedor administrado ADO.NET con patrones de codificación de acceso a datos similares a lo que se usan para otros proveedores administrados, como el proveedor administrado SQLClient de SQL Server. También es posible tener acceso a SSCE desde clientes no administrados con OLE DB. SSCE se ejecuta en un proceso como un conjunto de bibliotecas a las que hace referencia la aplicación que se usa, y es fácil de implementar con las bibliotecas de la aplicación o como una instalación de MSI independiente. SSCE puede implementarse fácilmente con aplicaciones ClickOnce o Xcopy en dispositivos móviles. SSCE también se instalará de forma nativa en Windows Mobile 6.0 o posterior.

El sistema de tipo SSCE es un subconjunto del sistema de tipo SQL Server 2005 y no admite todas las características que admite una instancia completa de SQL Server. Las características comúnmente usadas de SQL Server para aplicaciones de servidor que no están presentes en SSCE son, por ejemplo, procedimientos almacenados, desencadenadores, vistas, funciones, tipos de datos definidos por el usuario y capacidad de participar en mensajería de SQL Server Service Broker.

SQL Server 2005 Express Edition (SSE)

SSE es un servicio de motor de base de datos de pequeñas dimensiones (<55 MB) que se puede instalar en cualquier sistema operativo de escritorio o servidor Windows actual. Puesto que SSE se ejecuta como un servicio de Windows, requiere una instalación con Windows Installer (MSI) en el equipo del destino. SSE se puede implementar a través del programa previo ClickOnce para permitir que lo usen aplicaciones implementadas con ClickOnce. SSE admite el aislamiento de la instancia de usuario, que puede facilitar la implementación de ClickOnce y asegurar que los datos de un usuario están protegidos automáticamente contra los datos de otros usuarios.

SSE admite la mayor parte de las capacidades de una instancia completa de SQL Server, incluidas tablas, vistas, procedimientos almacenados, desencadenadores, funciones y CLR de SQL. Es posible tener acceso a los datos de una instancia de SSE desde el código administrado de la misma manera que se hace desde una instancia completa de SQL Server, con el proveedor administrado SQLClient. También es posible tener acceso a dichos datos desde aplicaciones no administradas con un proveedor OLE DB.

Las limitaciones de SSE en comparación con una instancia completa de SQL Server son bastante fáciles de entender. SSE usa sólo un procesador en el equipo aunque existan más; usa sólo 1 GB de memoria y sólo permite que el tamaño de las bases de datos crezca en 4 GB. Además, SSE puede ser suscriptor pero no editor de todas las clases de réplica, y puede enviar y recibir mensajes de SQL Server Service Broker siempre y cuando los mensajes se transmitan a través de una instancia completa de SQL Server (es decir, no puede existir mensajería de punto a punto entre instancias de SSE sin una instancia completa en la cadena).

Información general sobre SQL Server 2005 Compact Edition

Desde un punto de vista conceptual, SSCE puede considerarse una versión a escala considerablemente pequeña del motor de base de datos de SQL Server 2005. Sin embargo, se trata de un motor de base de datos separado diseñado para maximizar las características clave necesarias para un almacenamiento de datos sencillo, seguro y de transacción relacional a la vez que se minimizan los requisitos de disco, memoria e instalación para la aplicación de alojamiento.

Historia de SSCE

La herencia de SSCE muestra su origen en SQL Server CE 1.0, que se lanzó en 2001. Éste fue el primer motor relacional de datos que lanzó Microsoft para sistemas operativos de dispositivos móviles y se basaba en las capacidades de la base de datos de SQL Server 2000. A continuación, salieron las versiones 1.1 y 2.0 para mejorar la experiencia de usuario, con la 2.0 que proporcionaba además integración con aplicaciones de .NET Compact Framework. Junto con .NET 2.0 y SQL Server 2005, se lanzó SQL Server 2005 Mobile Edition como motor de base de datos móvil de última generación. SQL Server 2005 Mobile Edition ofrecía gran cantidad de características nuevas, como una mayor fiabilidad y mejor rendimiento, mejores opciones de sincronización y mejor integración tanto con SQL Server 2005 como con Microsoft Visual Studio 2005.

Cuando SSCE se presentó por primera vez en TechEd 2006, el nombre nuevo para esta versión fue anunciado como SQL Server 2005 Everywhere Edition. Este nombre sólo existió durante un período breve de tiempo entre el primer anuncio y el momento en que Microsoft reajustó los planes y las características de la versión de SSCE y los anunció junto con el nombre nuevo en TechEd Europe 2006, en noviembre de 2006. En consecuencia, es posible encontrar algún material en el que todavía aparezca en la Web con el nombre SQL Server 2005 Everywhere Edition o, de forma abreviada, Everywhere Edition (deben considerarse sinónimos de SSCE). Es importante tener en cuenta que SSCE es un motor de datos completamente diferente y con muchas más capacidades que las ediciones anteriores de SQL Server CE, de modo que se debe diferenciar claramente el uno del otro.

Funciones principales de SSCE

La función principal de SSCE es permitir el acceso y el almacenamiento de datos relacionales de transacción de forma segura. Mediante el motor de SSCE es posible ejecutar consultas SQL, entre las que se incluyen consultas de lenguaje de definición de datos (DDL) y de lenguaje de manipulación de datos (DML). Con SSCE, se crea una instancia de la base de datos como un solo archivo .sdf. Dentro de esa base de datos es posible definir tablas con claves y restricciones principales. SSCE admite la integridad de referencia completa a través de restricciones claves externas y eliminaciones y actualizaciones en cascada.

Además, SSCE admite las características siguientes:

  • Varias conexiones simultáneas para el acceso a datos de multiproceso.

  • La protección mediante contraseña y el cifrado de 128 bits del archivo de datos de SSCE .sdf.

  • Una gran variedad de tipos de datos de columna.

  • Cursores que se pueden desplazar y actualizar para un acceso a datos conectados rápido y fácil.

  • Bases de datos cuyo tamaño puede aumentar hasta los 4 GB.

  • Sincronización con SQL Server a través de una réplica de mezcla y el acceso a datos remotos (RDA).

Las nuevas capacidades de SSCE

De hecho, todas las características principales de SSCE formaban parte de SQL Server 2005 Mobile Edition, que se lanzó con SQL Server 2005 y .NET 2.0 en octubre de 2005. SSCE agrega varias características periféricas que la diferencian de Mobile Edition:

  • SSCE ahora se puede ejecutar en cualquier sistema operativo compatible Windows, como dispositivos móviles, Tablet PC, equipos portátiles o de escritorio y servidores.

  • SSCE se puede actualizar con Microsoft Update, Systems Management Server o Microsoft Windows Server Update Services.

  • SSCE se puede implementar con ClickOnce

Sincronización de datos con SSCE

Cuando SSCE se usa como una memoria caché de datos locales para una aplicación cliente o de nivel intermedio en una arquitectura de aplicaciones distribuidas, normalmente, es necesario poder sincronizar la base de datos de SSCE con un servidor de base de datos back-end. Es posible que precise rellenar las tablas de la base de datos de SSCE inicialmente desde una base de datos back-end y que también precise transmitir registros actualizados o nuevos desde el cliente hasta la base de datos del servidor.

Con SSCE, existen varias opciones para la sincronización. Existen dos opciones integradas de sincronización: réplica de mezcla y RDA. Estas dos capacidades permiten sincronizar los datos en una y otra dirección: desde una base de datos de SSCE a SQL Server 2005 o la base de datos de SQL Server 2000 en HTTP. Aparte de estas capacidades, es posible implementar una solución de sincronización personalizada realizando llamadas a sus propios extremos del servicio web expuesto, con lo que se permite la transmisión de datos a través de capas de lógica de negocios personalizadas en ambas direcciones en el servidor. Además, con la versión siguiente de Visual Studio (cuyo nombre de código es Orcas), existirá un subsistema nuevo de sincronización denominado el marco de sincronización OCS (Occasionally Connected Systems, sistemas conectados ocasionalmente).

Una réplica de mezcla es la opción de sincronización integrada más eficaz porque permite la actualización autónoma e independiente de registros tanto de las bases de datos del cliente (SSCE) y como del servidor (SQL Server) al mismo tiempo. SSCE participa en la réplica de mezcla como un suscriptor y puede suscribirse a publicaciones de réplica de mezcla expuestas de SQL Server 2000 o SQL Server 2005. Una réplica de mezcla administra muchos clientes fácilmente, porque también admite la detección y la resolución de conflictos desde el servidor. La configuración de una réplica de mezcla es un poco más complicada y requiere características de diseño de base de datos y una configuración específicas en el servidor.

RDA es la opción integrada de sincronización más fácil de usar. Con RDA, no existen requisitos específicos en la base de datos del servidor. Para sincronizar datos con RDA, se extrae un conjunto completo de resultados en la base de datos de SSCE desde el servidor para inicializar una tabla con los datos actuales del servidor. A continuación, puede transmitir los cambios (inserciones, actualizaciones y eliminaciones) al servidor cuando decida realizar la sincronización. Para obtener los cambios realizados en el servidor desde que se extrajeron los datos inicialmente, tiene que extraer el mismo conjunto de resultados de nuevo (después de transmitir los cambios para que los datos extraídos contengan los cambios). RDA no cuenta con ningún elemento de detección ni de resolución de conflictos de simultaneidad. Así, si lo usa con una aplicación en la que varios clientes pueden modificar distintos registros al mismo tiempo, el último cliente que escriba cambios en un registro puede sobrescribir cambios recientes entrados por otro cliente (el último cambio es el que prevalece).

Cuando se lance el marco de sincronización OCS, éste le permitirá elegir entre las capacidades de sincronización entre bases de datos semejantes a RDA y la réplica de mezcla, o un enfoque más orientado a servicios en el que el usuario conecta sus propios extremos del servicio en la canalización de sincronización. La configuración del enfoque anterior es más sencilla porque requiere una cantidad mínima de código personalizado. El último enfoque es un poco más complejo pero permite insertar la lógica de negocios entre el extremo del cliente y el servidor, y también permite establecer como destino otros orígenes de datos que pueden incluirse en un servicio de sincronización apropiado. En la figura 1 se muestra la arquitectura del nuevo marco de sincronización OCS.

Bb380177.Bb380177_01(es-es,SQL.90).gif

Figura 1. Marco de sincronización OCS

El marco OCS ofrece una solución lista para usar para la sincronización de datos orientada a servicios, así como numerosos puntos de extensión con el fin de permitir un control más explícito del proceso de sincronización. El cliente llama a través de un proveedor de sincronización para efectuar la sincronización de datos. El proveedor puede llamar a la lógica personalizada, como la lógica de validación, si es necesario. A continuación, el proveedor de sincronización, llama a través de un agente de sincronización al servicio de sincronización del servidor. El servicio expuesto puede ser un servicio que ofrezca el marco o uno personalizado que el usuario exponga. El servicio llama a través de un proveedor de sincronización en el destinatario, que a su vez puede llamar a la lógica personalizada. La sincronización se distribuye a través de un adaptador de sincronización apropiado y sus comandos de base de datos asociados. Los adaptadores y los comandos siguen una arquitectura semejante a TableAdapters asociada con conjuntos de datos con tipo ADO.NET 2.0.

Simultaneidad de SSCE

SSCE permite varias conexiones a la misma base de datos (archivo .sdf) de la misma aplicación o incluso de varias aplicaciones del mismo equipo. Esto le da más libertad para estructurar la aplicación como le convenga, como permitir que el usuario continúe interactuando con datos al realizar la sincronización con una base de datos de servidor o para que varias aplicaciones en del mismo equipo compartan un almacén de datos de SSCE. El motor de la base de datos bloquea las transacciones simultáneas para evitar que conexiones simultáneas tengan acceso a los mismos registros al mismo tiempo. El límite técnico de conexiones simultáneas para una sola base de datos es de 256, pero se recomienda no sobrepasar las 70 u 80, que es un límite más práctico desde el punto de vista del rendimiento.

Seguridad de SSCE

La seguridad y los permisos basados en funciones no se admiten en SSCE. Las bases de datos de SSCE están pensadas para ser usadas como un mecanismo sencillo de almacenamiento de datos para el almacenamiento de datos local y el acceso en un equipo cliente, o para el almacenamiento en caché de datos permanentes en un servidor de aplicaciones. Por este motivo, no se ha incluido la seguridad ni los permisos basados en funciones en las tablas con el fin de mantener el motor de la base de datos lo más pequeño y rápido posible. El control de acceso al conjunto de la base de datos en global se puede establecer a través del acceso protegido mediante contraseña. La protección de los datos mientras se almacenan en el disco puede efectuarse fácilmente mediante el cifrado de la base de datos.

Acceso a código no administrado de SSCE

SSCE también permite tener acceso fácilmente al almacén de datos desde aplicaciones no administradas. SSCE incluye un proveedor de OLE DB para que las aplicaciones que usan Microsoft Access, Microsoft Visual Basic 6, C++ u otras formas de código no administrado puedan tener acceso a datos colocados en una base de datos de SSCE y usarlos. Esto puede resultar práctico, por ejemplo, al migrar de aplicaciones no administradas y almacenes de datos heredados para pasar de forma progresiva a SSCE y al código administrado.

Rendimiento de SSCE

El rendimiento de SSCE es muy bueno para todas las situaciones de uso descritas en este documento. Si se compara el rendimiento de SSCE con el de SSE, EDB o Microsoft Access, no existe un ganador claro en todas las situaciones. Para cada combinación de tamaño de consulta, patrón de almacenamiento y otras variables, el rendimiento de un producto puede resultar mejor que otro, pero algunas tendencias se pueden evaluar coherentemente.

Si se compara SSCE con SSE, surgen algunos patrones de las pruebas de rendimiento. Las transacciones se inician y ejecutan de forma un poco más rápida (aunque sólo un pero 20 por ciento) en SSCE que en SSE. SSCE es más rápido que SSE para las consultas con parámetros que incluyen muchas filas (> 100), pero SSE es más rápido para inserciones de una sola fila o números de fila pequeños. SSCE es casi el doble de lento que SSE cuando la selección es de una sola fila y, en cambio, es igual de rápido cuando se trata de 100 filas o más, con el modelo conectado SqlCeResultSet. Sin embargo, con la API SqlCeConnection, la primera apertura y el último cierre son considerablemente más lentos en SSCE que en SSE (en ocasiones, > 1.000  veces más lento) debido a la gran sobrecarga que supone iniciar y apagar el motor de almacenamiento. Una forma que permite la optimización y la obtención de un mayor rendimiento es abrir SqlCeConnection antes de las transacciones y cerrarlo al final de todo. En este caso, el rendimiento es comparable a la de la API SqlCeResultSet.

Si se compara el rendimiento de SSCE con el de EDB en un dispositivo, EDB puede ser considerablemente más rápido (el 100 por ciento o más) en ciertas situaciones, como al determinar el tamaño de la base de datos y al realizar inserciones o actualizaciones. Sin embargo, la mayoría de operaciones de búsqueda y consulta son de un 20 a un 30 por ciento más rápidas en SSCE o son aproximadamente igual en lo que a rendimiento se refiere.

Diseño de soluciones con SSCE

Para entender cómo integrar SSCE en la arquitectura de aplicaciones, es mejor tratar su uso en el contexto de los cuatro tipos de aplicación resumidos anteriormente en estas notas del producto: las aplicaciones de fuerza de campo, las aplicaciones de administración de información personal (PIM), las aplicaciones cliente web a pequeña escala y el almacenamiento en caché del servidor de aplicaciones.

Aplicaciones de fuerza de campo.

Las aplicaciones de fuerza de campo (FFA) suelen ser aplicaciones cliente diseñadas para usarse en un dispositivo móvil, Tablet PC o en un equipo portátil como parte de un sistema distribuido mayor que se compone de varios niveles, servicios, bases de datos y otros elementos de arquitectura. Las FFA suelen compartir uno o varios de los atributos siguientes:

  • Permiten que el usuario realice sus tareas desconectado de la red del servidor: en las instalaciones de un cliente, durante un trayecto, en un aeropuerto o en el domicilio. Las FFA, normalmente, están diseñadas para la conectividad esporádica, lo que significa que cuando los usuarios usan la aplicación cliente, no precisan una conexión de red de ningún tipo.

  • En las FFA a menudo intervienen varios clientes que tienen acceso simultáneamente a datos de la base de datos del servidor y los usan, tanto estando conectados como desconectados.

  • Las FFA deben poder replicar datos de la base de datos del servidor a las bases de datos del cliente para obtener compatibilidad sin conexión. También deben poder replicar los registros de datos modificados, agregados o eliminados del cliente al servidor cuando la aplicación pueda conectarse a la red.

  • Las FFA deben poderse implementar con ClickOnce, lo que permite actualizaciones frecuentes a funcionalidades, así como a la base de datos usada para el almacenamiento local.

Ejemplos de FFA:

  • Aplicaciones de ventas POC (Point-of-Contact, punto de contacto) para la venta al por menor, seguros, inmobiliarias, administración financiera y muchos otros sectores.

  • Aplicaciones CRM (Customer Resource Management, administración de recursos del cliente) con alcance extendido para equipos distribuidos por dispositivos móviles, equipos portátiles y Tablet PC.

  • Aplicaciones de proveedores de asistencia sanitaria que permiten el acceso a historiales médicos, registro de las interacciones proveedor-paciente, solicitud de recetas médicas, laboratorios y diagnósticos, y la recopilación de datos de dispositivos de medida.

  • Aplicaciones de administración de inventario para almacenes, departamentos de transporte, servicios de administración de oficinas de negocios, suministros de porteros y otras aplicaciones que implican el registro y el seguimiento del recuento de elementos y que estén disponibles en ubicaciones de campo.

  • Aplicaciones de recopilación y medición de datos, como aplicaciones de empresas de suministros públicos, de telecomunicaciones, de sondeos, del censo y de emisión de voto.

Las arquitecturas de la solución FFA pueden variar en función del número y el tipo de plataformas cliente y el tamaño de la aplicación. En la figura 2 se muestra una arquitectura normal. Las FFA suelen estar formadas por varios clientes con plataformas de PDA/teléfono, Tablet PC, equipos portátiles o una combinación de éstas. Generalmente, se conectan a los servicios del servidor a través de conexiones seguras de servicios web o de una red privada virtual (VPN) de modo que se puedan sincronizar con datos del servidor desde cualquier conexión a Internet disponible, en lugar de tener que volver a la red local para ello. El cliente expuesto a ellas a menudo se coloca en una red del perímetro (también conocida como red perimetral, DMZ y subred filtrada) para limitar el número y el tipo de puertos que se abren desde dicha red, y se limitan las conexiones en la red del servidor. Para aplicaciones a mayor escala, el servidor web de la red del perímetro se puede conectar a un servidor de aplicaciones en el que se ejecuten los componentes de lógica de negocios y de acceso a datos, y dicho servidor de aplicaciones se comunica directamente con la base de datos del servidor.

Bb380177.Bb380177_02(es-es,SQL.90).gif

Figura 2. Arquitectura de aplicación de fuerza de campo

Para la sincronización de datos, a menudo se toma una ruta más directa para limitar la complejidad de la aplicación. Cuando se usa RDA o una réplica de mezcla, la arquitectura de sincronización se parece más a la de la figura 3. En tal caso, las aplicaciones cliente se conectan a través de HTTP a la base de datos del servidor, con Internet Information Services (IIS) y exponen el extremo HTTP a través del cual se efectúan las comunicaciones de sincronización.

Bb380177.Bb380177_03(es-es,SQL.90).gif

Figura 3. Arquitectura de la sincronización de fuerza de campo

Para tener acceso a datos desde el cliente, se pueden usar los métodos habituales de acceso a datos de ADO.NET desconectados, como los conjuntos de datos con tipo y los adaptadores de tabla asociados para leer y escribir datos desde un almacén de datos local de SSCE Northwind, como se muestra en el código de ejemplo siguiente. Como puede ver, los resúmenes del conjunto de datos con tipo eliminan todos los detalles del almacén subyacente, y el código de estos datos código de consumo no es distinto del que sería si los datos estuvieran en SQL Server, SSE o en otro almacén de datos al que se obtiene acceso a través de un proveedor administrado ADO.NET admitido. En CustomersTableAdapter, el diseñador de Visual Studio define los objetos SqlCeConnection y SqlCeCommand y éstos realizan todo el trabajo de recuperación y actualización de los datos en la base de datos de SSCE con patrones normales de acceso a datos de ADO.NET.

Ejemplo de código: Acceso a datos de lectura/escritura con conjuntos de datos con tipo

private NorthwindDataSet LoadDataSet()
{
    NorthwindDataSet nwData = new NorthwindDataSet();
    CustomersTableAdapter adapter = new CustomersTableAdapter();
    adapter.Fill(nwData.Customers);
    return nwData;
}

private void SaveChanges(NorthwindDataSet nwData)
{
    CustomersTableAdapter adapter = new CustomersTableAdapter();
    adapter.Update(nwData);
}

SqlCeResultSet también permite un modelo de acceso a datos conectado, tal como se muestra en el código de ejemplo siguiente. En este método, se crea SqlCeConnection, junto con SqlCeCommand para recuperar una fila de datos (aunque también funciona con conjuntos de resultados de varias filas). A continuación se abre la conexión, se ejecuta el comando para recuperar SqlCeResultSet y se realiza una actualización del registro de datos en éste. En este ejemplo sencillo, la conexión se cierra mediante un bloqueo, pero normalmente se usa SqlCeResultSet si es necesario retener dicha conexión para abarcar un mayor volumen de código, o si se desea poder leer y escribir en la base de datos sin tener que abrir y cerrar la conexión. En tal caso, no se cerraría la conexión inmediatamente después de usar el conjunto de resultados; se dejaría abierta y se cerraría SqlCeResultSet cuando se hubiera terminado de usar.

Ejemplo de código: Acceso a datos de lectura/escritura con SqlCeResultSet

private void UpdateCompanyName(string custId, string companyName)
{
    // Set up connection, just need path to sdf file 
    SqlCeConnection conn = 
        new SqlCeConnection(
           @"Data Source ='.\Northwind.sdf'");
    
    // Set up select query that brings rows into the result set
    string selQuery = 
       "SELECT * FROM Customers WHERE [Customer ID] = @CustID";
    SqlCeCommand getCustCmd = new SqlCeCommand(selQuery, conn);
    getCustCmd.Parameters.Add("@CustID", custId);

    using (conn)
    {
        conn.Open();
        // Pull the row into the result set, 
        // using options to allow connected, random, read-write access
        SqlCeResultSet resultSet = 
            getCustCmd.ExecuteResultSet(
               ResultSetOptions.Scrollable | 
               ResultSetOptions.Updatable);
        // Move to first record
        if (resultSet.ReadFirst())
        {
            // Get the column position
            int ordinal = resultSet.GetOrdinal("Company Name");
            // Set the value
            resultSet.SetString(ordinal, companyName);
            // persist
            resultSet.Update();
        }
        else // No match
        {
            throw new ArgumentException("Customer not found");
        }
    }
}

Aplicaciones de administración de datos personales

Las aplicaciones de administración de datos personales (PIM) son las aplicaciones sencillas de datos que se usan en almacenes de datos locales en plataformas móviles para el acceso y el almacenamiento de información personal de forma sencilla. Las aplicaciones PIM suelen compartir uno o varios de los atributos siguientes:

  • Se usan en plataformas móviles, incluidos teléfonos, PDA, Tablet PC o equipos portátiles.

  • Ofrecen una entrada y una búsqueda de datos sencillas en almacenes de datos locales para datos de aplicación

  • Son de dimensiones reducidas para permitir su disponibilidad disponibilidad en dispositivos móviles.

A continuación se indican algunos ejemplos de aplicaciones PIM:

  • Correo electrónico, mensajería instantánea, contactos, tareas, entrada de notas almacenamiento y recuperación.

  • Lector de noticias, Agregación de RSS.

  • Recuento de calorías, administración del tiempo, registro del ejercicio.

  • Tutor de idiomas, asesor de vocabulario, diccionario, tesauro.

  • Lista de la compra, colección de CD/DVD

La arquitectura de la solución para aplicaciones PIM es muy sencilla, como se muestra en la figura 4. Ésta sigue un diseño de cliente-servidor clásico en el que el servidor es un motor de base de datos local en el dispositivo o equipo portátil. EDB se puede usar en dispositivos móviles, pero SSCE es una opción más sencilla de usar, eficaz pero a la vez ligera para cualquier plataforma Windows, incluidos los dispositivos móviles. Por ejemplo, SSCE ofrece más compatibilidad para consultas que EDB y es más fácil desarrollar aplicaciones con SSCE en código administrado.

Bb380177.Bb380177_04(es-es,SQL.90).gif

Figura 4. Arquitectura de aplicaciones PIM

Una aplicación PIM que usa SSCE para un motor de base de datos normalmente usa la API SqlCeResultSet para simplificar al máximo la recuperación y el almacenamiento de datos. Este código es muy parecido al segundo código de ejemplo de la sección anterior.

Aplicaciones web a pequeña escala.

Para sitios web sencillos en los que se espera poco tráfico, no es necesario comprar software de servidor costoso ni pagar los elevados precios de las opciones de host que implican una instancia de la base de datos sólo para tener un sitio web dinámico y controlado por datos. SSCE y SSE ofrecen una opción sencilla y gratuita para almacenar datos dinámicos que se puede usar para representar contenido en páginas web. Si el sitio web usa ASP.NET o alguna otra tecnología web que permite el acceso a datos a través de un proveedor de OLE DB, los datos contenidos en las páginas del sitio pueden ser presentados mediante SSCE o SSE.

Las aplicaciones web adecuadas para SSCE o SSE son las que tienen una base de usuarios pequeña: el número total de usuarios puede ser elevado, pero el número de solicitudes simultáneas por segundo debe ser bastante bajo.

A continuación se indican algunos ejemplos de aplicaciones web que pueden ser candidatos para SSE o SSCE se encuentran:

  • Sitios de pasatiempos/clubes con una base de miembros pequeña

  • Organizaciones de grupos de usuarios pequeñas

  • Aplicaciones web internas para compañías pequeñas

A menos que el uso esperado de la aplicación web sea muy bajo y tenga pocas posibilidades de aumentar para volúmenes de usuarios más elevados, generalmente, SSE es una mejor opción para aplicaciones web a pequeña escala que SSCE. Si la aplicación continúa siendo una aplicación web de un solo proceso con un número muy bajo de solicitudes por hora (<de 300 a 500 solicitudes por hora, por ejemplo), SSCE o SSE debe poder administrar la capacidad de proceso necesaria.

Sin embargo, a medida que la complejidad de la aplicación crece y/o el número de solicitudes por segundo aumenta, SSE ofrece mejores opciones para ajustar de forma incremental la aplicación para satisfacer el aumento de la demanda. Tal como se ha descrito antes en este artículo, SSE admite procedimientos almacenados, funciones y otras características empresariales que pueden ofrecer una arquitectura con más capas y más desacoplada para aplicaciones complejas. Además, puesto que SSE se usa como un servicio, se ofrece más compatibilidad para el acceso simultáneo de varios procesos de aplicación web desde el mismo equipo o incluso desde distintos equipos. Existen más opciones de seguridad basada en funciones en SSE y la ruta de acceso de actualización a una versión completa de SQL Server es continua: no se requiere ningún cambio en el código de acceso a datos, porque SSE y SQL Server usan el mismo proveedor de datos. Además, los formatos de archivo de SSE y SQL Server son iguales, de modo que la base de datos de SSE puede estar conectada sólo a una instancia completa de SQL Server y estar preparada para funcionar. Cambiar de SSCE a SSE o a una versión completa de SQL Server requiere una migración de datos, así como una nueva codificación de parte de la lógica de datos, puesto que SSCE usa un proveedor de datos distinto de SSE o SQL Server.

Si decide usar SSCE para aplicaciones web, es necesario realizar algunas tareas de configuración para permitir que SSCE se aloje en el proceso de aplicación web.

Aplicaciones de almacenamiento en caché

Las aplicaciones de almacenamiento en caché pueden ser aplicaciones cliente o aplicaciones del servidor de aplicaciones que necesitan mantener una memoria caché de datos local de los valores de búsqueda o datos que raramente cambian para evitar viajes de ida y vuelta innecesarios a la base de datos del servidor. El almacenamiento en caché se usa para permitir que la aplicación recupere los datos necesarios del equipo local con el fin de mejorar el rendimiento y reducir el tráfico de red. Los casos en los que se usan aplicaciones de almacenamiento en caché son, por ejemplo, el acceso frecuente a listas de registros relativamente relativamente estáticos que se usan en presentaciones (listas desplegables de selección o referencia) o en las búsquedas del servidor de aplicaciones en la lógica de negocios.

Para obtener la recuperación de datos más rápida, los datos pueden almacenarse en la memoria caché y devolverse directamente cuando los valores de la memoria caché sean necesarios. Sin embargo, es posible que no desee o no pueda actualizar la memoria caché del servidor cada vez que se reinicia la aplicación, de modo que probablemente sea necesario un almacén de datos local para los valores almacenados en caché. Además, si las listas de valores que se almacenan en caché son muy importantes, como un catálogo de productos, quizás no desee conservar el catálogo completo en la memoria de la aplicación puesto que los elementos de esta lista sólo se consultan esporádicamente. Sea cual sea el motivo, usar SSCE como una ubicación de almacenamiento de la memoria caché de datos local puede ser una buena elección para su arquitectura.

Los datos de la memoria caché deben inicializarse desde el servidor la primera vez que se ejecuta la aplicación y a menudo tienen una fecha u hora de caducidad asociado cuando la memoria caché debe actualizarse desde el origen. El tiempo de espera asociado a la memoria caché viene determinado por los requisitos de la aplicación, la frecuencia con la que los datos cambian y la latencia en los datos almacenados en caché que pueden tolerar la aplicación y los usuarios.

Al diseñar una memoria caché de datos en una aplicación, debe elegir entre una estrategia de almacenamiento de datos pasiva o activa. Con el almacenamiento en caché pasivo, la aplicación trata de obtener los datos necesarios de la memoria caché de datos local. Si los datos no aparecen, la lógica de aplicación recupera los datos del servidor y almacena los resultados en la memoria caché para recuperaciones posteriores. Si la memoria caché pasa a ser no válida porque se ha excedido el tiempo de espera o por otros motivos, la aplicación debe actualizar la memoria caché desde el origen. Con el almacenamiento en caché activo, la memoria caché se mantiene actualizada activamente según algunos criterios, como por ejemplo, una actualización programada desde el servidor. Si se usa una estrategia de almacenamiento en caché activa, el código de la aplicación es más sencillo porque siempre podrá simplemente consultar la memoria caché local para obtener sus datos. Sin embargo, se requiere código adicional para inicializar la memoria caché activa y mantenerla actualizada.

Para una aplicación de almacenamiento en caché, quizá desee efectuar el almacenamiento en dos niveles. Es posible que desee almacenar en caché los datos en un almacén permanente, como SSCE, para permitir que la memoria caché resida en la máquina local para superar los reinicios de la aplicación o evitar tener que cargar todos los datos en caché a la memoria. Sin embargo, también es posible que desee almacenar en caché algunos de los datos de la memoria caché permanente de la memoria para ofrecer una recuperación de datos lo más rápida posible cuando éstos sean necesarios (por ejemplo, para llevar a cabo la lógica de rellenado automático en los controles de entrada de cuadros de texto o de listas desplegables). Para estos dos niveles de almacenamiento en caché, es posible usar la misma estrategia de almacenamiento en caché o una distinta (activa en lugar de pasiva, por ejemplo).

En la figura 5 se muestra una arquitectura de aplicación de almacenamiento en caché de ejemplo, con cachés existentes tanto en la aplicación cliente como en el servidor de aplicaciones de nivel intermedio. La aplicación cliente almacena en caché los datos tanto en el almacén permanente de SSCE como en la memoria porque generalmente el consumo de memoria no es tan problemático en una aplicación cliente. La memoria caché del servidor de aplicaciones almacena las listas de búsquedas grandes, como los catálogos de productos, de forma permanente para evitar el consumo de memoria por motivos de escalabilidad, pero impide que el rendimiento se vea afectado debido a los viajes de ida y vuelta al servidor de la base de datos siempre que se requiere realizar una búsqueda en el catálogo de productos, como por ejemplo, localizar todos los productos que se encuentren dentro de un determinado intervalo de precios. La diferencia principal entre una aplicación de almacenamiento en caché y otra que realiza sincronizaciones (como una aplicación de fuerza de campo) es que, en una aplicación de almacenamiento en caché, los datos sólo se extraen del servidor a la memoria caché de datos local. Con la sincronización, los datos de la memoria caché también se sincronizan con la base de datos del servidor una vez realizadas las modificaciones.

Bb380177.Bb380177_05(es-es,SQL.90).gif

Figura 5. Arquitectura de aplicaciones de almacenamiento en caché

Conclusión

Muchas aplicaciones precisan un almacén de datos seguro, con capacidad de transacción, permanente y eficaz, pero no requieren necesariamente la gama completa de capacidades que ofrece SQL Server 2005. SSCE ofrece un motor de base de datos gratuito, eficaz y fácil de usar que se puede emplear en una gran variedad de situaciones de aplicación y arquitecturas. Se puede usar en aplicaciones de fuerza de campo, aplicaciones de administración de datos personales, aplicaciones web pequeñas o aplicaciones de almacenamiento de datos en caché. Ofrece varias opciones actuales y futuras de sincronización de datos para que pueda formar parte de una arquitectura de aplicaciones distribuidas mayor que implican el uso de bases de datos de SQL Server 2005 de servidor. SSCE debería ser una de las tecnologías de base de datos que tener en cuenta para cualquier aplicación que necesite un almacén de datos relacional ligero.

Acerca del autor

Brian Noyes es responsable de arquitectura de IDesign (http://www.idesign.net/), una empresa de cursos y consultoría de arquitectura y diseño de .NET. Es director regional de Microsoft y MVP (Most Valuable Professional) de Microsoft, además de un escritor y conferenciante conocido en todo el mundo. Su último libro, Smart Client Deployment with ClickOnce, forma parte de la serie .NET Development de Addison Wesley, publicada en diciembre de 2006. Su libro anterior, Data Binding with Windows Forms 2.0, continúa en la lista de los más vendidos. Puede ponerse en contacto con él escribiendo a brian.noyes@idesign.net o a través de su blog en http://www.softinsight.com/bnoyes.

Para obtener más información

http://www.microsoft.com/sql/editions/compact/default.mspx

Mostrar:
© 2015 Microsoft