¿Hay alguna desventaja en usar Access como base de datos?

Heredé una aplicación que almacena datos en varias tablas en Microsoft Access; Access DB solo se usa para el almacenamiento, todo el procesamiento de datos es manejado por la aplicación (VB.net).

¿Es esta una buena práctica? Necesito crear una aplicación similar desde cero y no estoy seguro de lo que es una práctica 'normal'.

Intenté buscar en Google la pregunta en varios formatos y revisé numerosos resultados (incluidos muchos en este foro), pero todas las preguntas parecen estar relacionadas con dónde está programando dentro de Access en lugar de simplemente usarlo para el almacenamiento de datos.

Supongo que podría ser más específico y decir que SQL Server Express o similar sería una mejor opción y, de ser así, ¿por qué?

Si está leyendo esta publicación debido a una pregunta similar, consulte este enlace proporcionado por @DanielB a continuación: /programming/694921/ms-access-mdb-concurrency

Las bases de datos de MSAccess generalmente no se usan por un par de razones. En el pasado, eran escamosas y no aceptaban múltiples conexiones a la vez. Cuando se utiliza la base de datos MSAccess, se crea un archivo de bloqueo (ldb). Cuando ese archivo de bloqueo está presente, nadie más puede acceder a la base de datos. Descubrí que cuando había una aplicación de un solo uso, el rendimiento de MSAccess se degradaría severamente después de aproximadamente 50k filas. Probablemente esto sea mejor ahora, pero ciertamente no fue ajustado para usos más grandes.

Lo que es más típico es usar un sistema de base de datos más robusto como postgres, mysql o MSSQL. Para bases de datos de conexión única, he usado Derby (con Java).

En lo que respecta a VB, no encontrará soluciones profesionales que utilicen VB como software de cliente para una base de datos. Bueno, tal vez hay algunas soluciones que se venden, pero personalmente, las evitaría.

Por lo general, su procesamiento se realizará en un lenguaje como C #, C ++, Java, Perl, Python u otros lenguajes populares. Las bibliotecas se utilizarán para conectarse a la base de datos que están separadas del idioma. Algunas soluciones usarán SQL para consultar y recibir datos, y otras soluciones usarán una biblioteca de Persistencia para crear objetos a partir de los datos (esto se está volviendo más común).

En cuanto a las mejores prácticas, siempre he encontrado que es mejor ser consistente. Si tiene una tienda de cuatro personas que entienden MSAccess y VisualBasic, entonces tiene mucho sentido continuar haciéndolo de esta manera. Si hay un objetivo en la empresa para alejarse de él debido a fallas en el pasado, puede seguir usando VB y cambiar a otra base de datos. Examine las tablas de enlaces en MSAccess: utilicé una aplicación VB en una base de datos MSSQL al vincular las tablas MSSQL en una base de datos MSAccess. El VB no sabía la diferencia entre una tabla ingenua de MSAccess y una tabla vinculada ubicada en otro servidor. La solución VB todavía era escasa, pero funcionaba mucho mejor con conjuntos de datos más grandes.

¡Espero que esto ayude!

He tenido alguna experiencia con respecto a este tema en el pasado en una gran corporación.

A medida que crecía la base de usuarios, surgieron problemas de seguridad y rendimiento porque los archivos de Access donde residían los datos tenían que almacenarse en una carpeta compartida de red, y todos los usuarios tenían que tener acceso W / R a ellos.

Esto no es teórico, es una experiencia del mundo real, las bases de datos de Access no se adaptan bien a decenas de usuarios simultáneos, y mucho menos a un par de cientos distribuidos geográficamente.

Con sistemas de bases de datos gratuitos y buenos como PostgreSQL disponibles, hay pocas razones para usar Access, excepto las siguientes: falta de conocimientos técnicos.

Personalmente, si puede alejarse del acceso, hágalo, he tenido clientes que realmente han sufrido porque simplemente no podían o no "morderían la bala".

Como Kieveli mencionó, las bases de datos de Access son horribles cuando se trata de almacenar grandes cantidades de datos, recuerde que las aplicaciones siempre deben diseñarse teniendo en cuenta el beneficio para el usuario final. ¿Imagina que tiene una oficina llena de personas que tienen un sistema terriblemente lento y pierden horas de su tiempo cada semana?

Hablando por experiencia personal, mover una base de datos de acceso a SQL Server realmente no es tan doloroso siempre que planifique correctamente, la pregunta es si tiene las habilidades técnicas internas para pasar a algo como vb.net, etc.

Las bases de datos de Access no se escalan bien, pero son fáciles de manejar y distribuir. Si está utilizando un Mapeador Relacional de Objetos (O / R-mapper) que admite diferentes tipos de bases de datos como interfaz para su base de datos, su aplicación dependerá mucho menos de un tipo de base de datos específico. Esto le permite comenzar con Access y pasar a otra base de datos más adelante.

Hice esto una vez y comencé un proyecto con Access y un front-end C #, porque las bases de datos se pueden configurar y desarrollar muy fácilmente con Access. Más tarde me mudé a una base de datos Oracle porque mi cliente tiene una base de datos Oracle. Solo unos pocos cambios fueron necesarios en mi solicitud.

Jet-SQL está horriblemente documentado. Eso solo es una razón para que me mantenga alejado de Access.

/programming/11265817/where-can-i-find-a-complete-reference-for-microsoft-access-sql

T-SQL (SQL Server), por otro lado, es mucho más flexible y puede encontrar toneladas de documentación, blogs y expertos que pueden ayudarlo.

Por supuesto, Access es una base de datos de escritorio, mientras que SQL Server es una base de datos cliente-servidor completa.

Existen algunas otras bases de datos de escritorio (he estado usando Advantage Database Server, pero ese también es un producto de nicho).