vincular tablas sqlserver migrar mdb importar exportar datos como acces php asp.net sql ms-access

php - tablas - Convencer a un gerente de TI para que permita SQL Server en lugar de Access



migrar access a sql server 2005 (12)

Aquí hay un documento de Microsoft que podría ayudar:

Acceso frente al servidor Sql

Otro artículo .

Mis propios pensamientos personales, Access no tiene cabida en un entorno que podría escalar más allá de más de dos o tres conexiones simultáneas. ¿Usarías Excel como back-end?

Un IT Manager no permite el uso de SQL Server con un sitio web ASP.NET en desarrollo. La configuración actual que se reemplaza es un sitio php que se conecta a una base de datos de Microsoft Access. Tengo algunas razones propias sobre por qué se debe usar SQL, pero quisiera tantos argumentos fuertes como sea posible (estudiante vs. Hombre de TI). ¿Alguien tiene argumentos contundentes sobre por qué debería usarse SQL? Particularmente posado con un gerente de TI que ha declarado que "esta es la forma en que lo hemos estado haciendo, y [ha] estado funcionando".

¡Gracias por adelantado!

ACTUALIZAR

Con el interés de ''descargar'' esta pregunta ... ¿Si recomendaría mantener el acceso, cuándo y por qué?

Considere la opción de que tal vez él tiene razón. Si funciona bien con Access, simplemente déjalo así. Si hay problemas de escalabilidad en el futuro (el sitio se usa de más de 1 usuario simultáneamente), es su problema, no el suyo.

También considere sqlite, puede ser mejor que el acceso

El acceso no trata muy bien a múltiples usuarios (¿nada?). Esto significa que si tiene más de una persona tratando de acceder o especialmente actualizar su sitio, es muy probable que muera o, en el mejor de los casos, sea muy lento.

Hay herramientas mucho mejores en SQL Server (linq a sql o entity framework o cualquier cantidad de ORM).

SQL Express es una opción mucho mejor que el acceso para un backend de sitio web y es gratis.

Licencia para uno. Dudo que quiera tener cientos de licencias de Office (una por cada usuario final que se conecte al sitio). SQL tiene licencias que permiten múltiples conexiones al mismo tiempo sin licencias de conexión específicas.

Sin mencionar problemas de escalabilidad y confiabilidad. SQL Server ios diseñado para ser utilizado y administrado en un entorno 24/7. El acceso no tiene.

SQL puede escalar a squillions de conexiones simultáneas, Access no puede.

SQL puede hacer copias de seguridad mientras está funcionando, Access no puede.

SQL está diseñado como un repositorio de datos altamente robusto, Access no está diseñado con los mismos requisitos en mente.

No olvide que para algo tan pequeño como la mayoría de las bases de datos de Access, puede usar SQL Server Express Edition, que es gratis, por lo que no le costará nada.

Su gerente ha declarado la razón por la que quiere usar Access. ¿Eres responsable de diseñar una alternativa? ¿Tiene alguna razón para pensar que se beneficiará si demuestra que su gerente está equivocado? ¿Cuál es tu ventaja personal en esta conversación? ¿Estás seguro de que Access no será "lo suficientemente bueno"? ¿El sitio rediseñado va a tener heaver o cargas diferentes (es decir, más usuarios o diseño menos eficiente)? No estoy seguro de que quiera discutir con su gerente que no puede implementar algo que funcione tan bien como el diseño anterior.

Va a ser mucho más fácil dejar que el proyecto falle (si esperas que sea el resultado) y rescatarlo con SQL Server, que hacer que tu gerente reconozca que entiendes la situación mejor que él.

Una razón simple para usar SQL Server en lugar de una base de datos de Microsoft Access: El MS Access DB puede resultar en un cuello de botella si la base de datos se utilizará en gran medida por muchos usuarios.

¡MS Access es para 1 usuario de escritorio 1! Estuve pasando un año en un proyecto anterior para desconectar una aplicación (creciendo al tamaño de la empresa en términos de usuarios) de Access debido a su extraño comportamiento de bloqueo y su desempeño horrible. SQL Server Express Edition es un buen punto de partida, como se hizo eco de publicaciones anteriores.

No discutir, compararlo. Los datos reales deberían triunfar sobre la retórica (¡en un mundo racional, al menos! ;-)

Configura el cuadro de texto con las dos alternativas y ejecútalas con fuerza. (Si está exponiendo servicios web, puede usar una herramienta como SoapUI para pruebas de estrés automatizadas. Hay muchas otras herramientas en este espacio). Recopile estadísticas y analícelas para determinar las compensaciones.

Realice una prueba de carga de su producto terminado y demuestre que Access no está destinado a impulsar sitios web.

Escriba su código para que pueda cambiar la base de datos fácilmente. Luego, cuando el acceso falla, migre sus datos a una base de datos real, o MySQL, si es necesario.

Estas son algunas herramientas de estrés del servidor web de Microsoft

Para el registro, es posible enviar comandos en su mayoría SQL a la base de datos y no mantener abierta una conexión activa, lo que permite más de 6 o 7 conexiones a la vez, pero el hecho es que el acceso no está destinado a hacerlo. Entonces, el punto "funciona bien" es como decir que está bien limpiar el piso con cinta adhesiva: funciona, pero no es la herramienta adecuada para el trabajo.

RESPUESTA ACTUALIZADA A LA PREGUNTA ACTUALIZADA:

Realmente la clave aquí es la separación de acceso a datos en su código. Debería poder tener más o menos la estructura de la base de datos de datos en cualquier cantidad de DBMS. Las cosas pueden complicarse, pero un mapa de tablas debe ser universal. Entonces, si el acceso no funciona, decida utilizar una base de datos diferente.

El acceso PUEDE ser utilizado en sitios poco transitados. Con las rutinas solo de declaración SQL, pude construir un sitio de comercio electrónico que ganaba un par de millones al año en ventas y tenía 60,000 visitantes al mes. Es posible, pero quizás no ideal. Esos no son números grandes, pero son los más grandes para cualquier sitio en el que haya participado.

Mantenga el acceso si el Administrador de TI está demasiado ocupado para mantener otro servidor o si no desea perder tiempo configurando uno. En última instancia, adivinar no hace nada, y las pruebas te dicen todo lo que necesitas saber. Pruebe y tome decisiones sobre los resultados.

Simplemente tome una suite de pruebas (o simplemente junte una):

  1. compare el tiempo necesario para crear un DB con 1000,000 enteries.
  2. buscar una entrada en el db.
  3. Vacunar el db
  4. Eliminar el archivo db
  5. Haga un par de operaciones que crea que se realizarán más en el DB varias veces.

y hazlo frente a él para comparar (escribe un guión). Supongo que tu gerente de TI está bromeando o que el sitio en el que estás trabajando no es crítico y no quiere asignar recursos (incluyéndote a ti).