visual - ¿Cuáles son las limitaciones de SQL Server Compact?(O bien, ¿cómo se elige una base de datos para usar en plataformas MS?)

sql server compact ado net data provider

Question

La aplicación que quiero compilar utilizando MS Visual C # Express (estoy dispuesto a actualizar a Standard si es necesario) que necesita una base de datos.

Estaba totalmente emocionado con el SQL Server Compact, porque no quiero que las personas que instalarían mi aplicación en sus computadoras tengan que instalar todo el SQL Server o algo así. Quiero que esto sea lo más fácil posible para que el usuario final lo instale.

Así que estaba emocionado hasta que parece que hay limitaciones en lo que puedo hacer con las columnas de mis tablas. Creé una nueva base de datos, creé una tabla y cuando fui a crear columnas parece que no hay un tipo de datos de "texto", simplemente algo llamado "ntext" que parece estar limitado a 255 caracteres. "int" parece estar limitado a 4 (yo quería 11). Y no parece haber una característica de "autoincremento".

¿Son estas las verdaderas limitaciones con las que tendría que vivir? (O es porque estoy usando "Express" y no "Estándar"). Si estas son las limitaciones reales, ¿cuáles son mis otras opciones de base de datos que cumplen mis requisitos? (Instalación fácil para el usuario: supongo que mi usuario final es solo un usuario promedio de computadoras y si es complicado se sentiría frustrado con mi aplicación)

-Adeena

PD: también quiero que los datos de mi base de datos se cifren para el usuario final. No quiero que puedan acceder directamente a las tablas de la base de datos.

PPS. Leí: http://www.microsoft.com/Sqlserver/2005/en/us/compact.aspx y no vi una discusión sobre estas limitaciones particulares

Answer 1

Hay limitaciones ... Joel parece haber abordado los detalles. SQL CE está realmente orientado al desarrollo móvil. La mayoría de las soluciones de bases de datos "integradas" tienen limitaciones similares. Revisa

• SQLite

  • Sin límite de caracteres de campo TEXT
  • Aumento automático solo en la columna INTEGER PRIMARY KEY
  • Algún tipo de soporte de encriptación de terceros

• Esent

  • (El código no administrado no es mi fuerte, y no puedo descifrar los documentos no administrados )

Answer 2

He usado varias ediciones de SQL Server Compact en algunas ocasiones, pero solo como repositorios de captura de datos en plataformas móviles, donde funciona bien para sincronizar con una base de datos de servidor, y con ese tipo de escenario es, sin duda, la elección opcional.

Sin embargo, si necesita hacer algo más que eso y actuar como una base de datos primaria para su aplicación, le sugiero que SQLLite es probablemente la mejor opción, es completamente sólida, ampliamente compatible y se encuentra en todo tipo de lugares (utilizado en el iPhone para ejemplo) pero es sorprendentemente capaz (el simulador de Realidad Virtual OpenSim lo usa ya que es una base de datos predeterminada) y hay muchos otros (incluido Microsoft).

Answer 3

SQL CE es un rompecabezas para mí. ¿Realmente necesitábamos otra plataforma de base de datos SQL diferente? Y es el tercero en los últimos años dirigido a las plataformas móviles de MS ... No tengo mucha confianza de que será el último. No comparte mucha tecnología con SQL Server, es una nueva desde el principio hasta donde yo sé.

Lo probé y luego tuve más éxito con SQLite y Codebase.

EDITAR: Aquí hay una lista de las (muchas) diferencias.

Answer 4

Tuve que intervenir en dos factores:

1. Uso Sql Compact mucho y es excelente para lo que funciona: un solo usuario, base de datos incrustada, con un solo almacén de datos de archivo. Tiene todas las bondades y transacciones de SQL. Tiene paralelismo bastante bien para mí. Tenga en cuenta que algunos de los detractores de esta página usan el producto regularmente. No lo use en un servidor, no es para eso. Muchos de mis clientes ni siquiera saben que el archivo es una "base de datos", es solo un problema de implementación.
2. Desea encriptar los datos de sus usuarios, presumiblemente para que solo puedan verlos desde su programa. Esto simplemente no va a suceder. Si su programa puede descifrar los datos, entonces debe almacenar la clave en algún lugar, y un atacante suficientemente dedicado la encontrará, punto.

Es posible que pueda ocultar la clave lo suficientemente bien como para que el esfuerzo por recuperarla no valga la pena el valor de la información. Windows tiene algunas rutinas de encriptación locales precisas de máquina y usuario para ayudar. Pero si su diseño tiene un fuerte requerimiento de que un usuario nunca encuentre datos que haya ocultado en su computadora (pero lo hará su programa) deberá rediseñar: esa garantía simplemente no se puede lograr.

Answer 5

De acuerdo con este post ( http://www.nelsonpires.com/web-development/microsoft-webmatrix-the-dawn-of-a-new-era/ ) dice que debido a que usa un archivo de base de datos, solo un proceso puede acceda a él para cada lectura / escritura y como resultado necesita acceso exclusivo al archivo, también está limitado a 256 conexiones y el archivo completo probablemente tendrá que cargarse en la memoria. Entonces, SQL Server Compact podría no ser bueno para su sitio cuando crezca.

Answer 6

Algunos, con suerte, útiles comentarios:

Primero: no use SQLite a menos que desee tener la base de datos completa bloqueada durante las escrituras ( http://www.sqlite.org/faq.html#q6 ) y, quizás más importante, en una aplicación .NET, NO sea segura para subprocesos o más al punto, debe ser recompilado para soportar hilos ( http://www.sqlite.org/faq.html#q6 )

Como alternativa para mi proyecto actual, busqué en Scimore DB (tienen una versión integrada con el proveedor ADO.Net: http://www.scimore.com/products/embedded.aspx ) pero necesitaba usar LINQ To SQL como un O / RM así que tuve que usar Sql Server CE.

El incremento automático (si se refiere al incremento automático de la clave) es lo que siempre ha sido - tabla de ejemplo:

- Usuarios de mesa

CREATE TABLE Tests (
Id **int IDENTITY(1,1) PRIMARY KEY NOT NULL,**
TestName nvarchar(100) NOT NULL,
TimeStamp datetime NOT NULL
)
GO

En cuanto al tamaño del texto, creo que fue respondido.

Aquí hay un enlace a la información sobre encriptación de microsoft technet: ( http://technet.microsoft.com/en-us/library/ms171955.aspx )

Espero que esto ayude un poco....

Answer 7

ntext admite datos de texto muy grandes (consulte MSDN : esto es para Compact 4.0, pero lo mismo se aplica a 3.5 para los tipos de datos que menciona).

int es un tipo de datos numéricos, por lo que el tamaño de 4 significa 4 bytes / 32 bits de almacenamiento (-2,147,483,648 a 2,147,483,647). Si tiene la intención de almacenar 11 bytes de datos en una sola columna, use el tipo varbinary con un tamaño de 11.

Las columnas de incremento automático en el mundo de SQL Server se realizan con la palabra clave IDENTITY . Esto hace que el valor de la columna sea determinado automáticamente por SQL Server al insertar datos en una fila, evitando colisiones con otras filas.

También puede establecer una contraseña o cifrar la base de datos al crearla en SQL Compact para evitar que los usuarios accedan directamente a su aplicación. Consulte Proteger las bases de datos en MSDN .

Todos los elementos que mencionas arriba no son realmente limitaciones, tanto como que están entendiendo cómo usar SQL Server.

Habiendo dicho eso, hay algunas limitaciones para SQL Compact.

• Sin soporte para NVARCHAR(MAX)
  • NTEXT funciona bien para esto
• Sin soporte para VIEW s o PROCEDURE s
  • Esto es lo que veo como la principal limitación

Answer 8

No estoy seguro sobre el cifrado, pero probablemente este enlace le resulte útil:
http://msdn.microsoft.com/en-us/library/ms171955.aspx

En cuanto al resto:
"Texto" y "autoincremento" me recuerdan a Access. Se supone que SQL Server Compact es una actualización compatible con las ediciones de servidor de SQL Server, en el sentido de que las consultas y tablas utilizadas en su base de datos compacta deberían transferirse a una base de datos completa sin modificaciones. Con esto en mente, primero debe ver los tipos y nombres de SQL Server en lugar de los nombres de acceso: en este caso, a saber, varchar(max) , bigint e identity .

Desafortunadamente, notará que esto falla con respecto a varchar (max), porque Compact Edition aún no tiene el tipo varchar (max). Espero que lo arreglen pronto. Sin embargo, el tipo de texto n que estabas viendo soporta muchos más de 255 bytes: 2 ³⁰ de hecho, lo que equivale a más de 500 millones de caracteres.

Finalmente, bigint usa 8 bytes para almacenamiento. Usted solicitó 11. Sin embargo, creo que puede estar confundido aquí que el tamaño de almacenamiento indica la cantidad de dígitos decimales disponibles. Este definitivamente no es el caso. 8 bytes de almacenamiento permiten valores de hasta ⁶⁴ , que acomodarán muchos más de 11 dígitos. Si tiene tantos elementos, probablemente quiera una base de datos de clase servidor de todos modos. Si realmente quiere pensar en términos de dígitos, también se proporciona un tipo numeric .

Answer 9

También debo entrar aquí con VistaDB como una alternativa a SQL CE.

VistaDB no es compatible con el cifrado (Blowfish), sino que también es compatible con TEXT y NTEXT (incluidos los índices FTS).

Y sí, la publicación anterior es correcta, ya que tiene que ver los tipos de SQL Server para realmente compararlos, VistaDB también usa los tipos de SQL Server (en realidad admitimos más que SQL CE, solo falta XML).

Para ver otras comparaciones entre VistaDB y SQL CE, visite la página de comparación. Consulte también el hilo SO en Ventajas de VistaDB para obtener más información.

(Divulgación completa - Soy el dueño de VistaDB, por lo que puedo ser parcial)