¿Cómo elegir la versión ligera del sistema de base de datos?

Estoy empezando un proyecto de punto de venta. El sistema de segmentación se escribirá en C # .NET 2 WinForms y como servidor de base de datos principal. Vamos a utilizar MS-SQL Server. Como tenemos muchos dispositivos POS en cadena para una tienda, me encantará tener un sistema de base de datos local en cada dispositivo POS.

Los escenarios son los siguientes: ¡Cuando el servidor principal se cae! La aplicación de POS debe continuar trabajando “fuera de línea” con la base de datos local, hasta que la conexión al servidor principal vuelva a aparecer.

Ahora estoy en el dilema de qué base de datos local será la más adoptable para mí. Aquí hay algunas notas para ayudarme a señalarme en la dirección correcta:

  1. Para ser Ligero “Mis dispositivos POS suelen ser viejos y sufren con actuaciones”
  2. Para ser libre “Tengo muchos dispositivos y no tengo un costo adicional al lado del seridor SQL principal”
  3. Un día me encantaría probar todo ese puerto en los sistemas operativos Mono y Linux.

Esto es lo que he investigado hasta ahora:

  1. XML simple “Ligero, pero temo el rendimiento. Mi tabla principal de elementos es un promedio de registros de 10K”
  2. SQL-Express “Me temo que mis dispositivos POS son deficientes con el hardware para SQLExpress y también es difícil de instalar en cada dispositivo y configurar”
  3. El servidor de base de datos Advantage, menos conocido, tiene distribución gratuita del sistema ADT fuera de línea.
  4. DBF con la biblioteca extendida, “Respeto por las buenas DBF antiguas, pero esa era está detrás de Mí con clipper y DBF”
  5. MS Access
  6. Sqlite “En su mayoría me gusta por ahora, pero me temo que se vaya a emparejar con MS SQL si tienen los mismos tipos de datos”.

Sé que en este SO hay una gran cantidad de datos subjetivos, pero al menos alguien puede recomendar algún otro sistema de base de datos lite, o las cosas que más me han llamado la atención antes de elegir la base de datos.

SQL Server Compact

Está diseñado para dispositivos integrados (es decir, Windows Mobile), pero también puede ejecutarse en PC. Es de 2 MB, se ejecuta en el proceso, un solo archivo de base de datos, que puede tener el nombre que desee.

Se entiende como una base de datos local de alto rendimiento. No puede conectarse a él de forma remota y no admite procedimientos almacenados o funciones definidas por el usuario.


Pero para responder a su pregunta real: ¿cómo elegir?

Elija lo que tienen las herramientas de administración, con una ruta de actualización fácil y compatible cuando lo supere.

Estoy haciendo lo mismo: el servidor central probablemente ejecuta el servidor MS SQL y los sistemas distribuidos, aunque estos ejecutan Linux. Optamos por realizar la transferencia de datos en XML y usar sqlite en los sistemas distribuidos.

Es temprano, pero parece que va bien hasta ahora.

Hay enlaces .net para sqlite.

La razón por la que elegimos sqlite fue:

  1. porque no necesita ninguna gestión de base de datos, lo que sería complicado en los sistemas remotos.
  2. Parece muy utilizado: por ejemplo, firefox usa sqlite para el almacenamiento local.
  3. Podemos usarlo en Windows y Linux.
  4. Se supone que es bueno para no perder datos si se produce un corte de energía inesperado.

Sugeriría Sql Compact Edition, ya que es ligero y gratuito, por lo que resuelve dos de sus tres problemas. No tengo idea si funciona en Mono …..

Lo he usado en el pasado y, de hecho, me impresionó bastante el rendimiento. El único gran inconveniente es la falta de procedimientos almacenados …

Utilizo System.Data.Sqlite, que es un contenedor de código abierto de ADO.Net alrededor de Sqlite de http://sqlite.phxsoftware.com/ . Puedes usarlo desde Visual Studio para construir bases de datos. Es compatible con un subconjunto de los tipos de campo de Sql Server, y escribir una clase de interfaz entre las dos bases de datos debería ser instantáneo. Y obtiene los beneficios de una implementación simple al incluir una única DLL en su proyecto y una base de datos de un solo archivo. E incluye cifrado, también.