ms-access - usuarios - cómo convertir una base de datos access en una página web
Bases de datos de MS Access en redes lentas: ¿es más rápido separar los back ends? (1)
Tengo una base de datos de Access que contiene información sobre personas (perfiles de empleados e información relacionada). La interfaz tiene una interfaz única similar a una consola que modifica un tipo de datos a la vez (como grados académicos de un formulario, información de contacto de otro). Actualmente está vinculado a múltiples back ends (uno para cada tipo de datos y otro para la información básica del perfil). Todos los archivos están ubicados en un recurso compartido de red y muchos de los back-ends están encriptados.
La razón por la que lo hice es que entiendo que MS Access tiene que extraer todo el archivo de la base de datos a la computadora local para realizar consultas o actualizaciones, y luego volver a poner los datos modificados en el recurso compartido de la red. Mi teoría es que si una persona cambia un número de teléfono o dirección (información de contacto), solo tendrían que extraer / modificar / reemplazar la base de datos de información de contacto, en lugar de extraer una única gran base de datos que contenga información de contacto, proyectos, títulos, premios. , etc. solo para cambiar un número de teléfono, reduciendo así el potencial de bases de datos bloqueadas y tráfico de red cuando varios usuarios acceden a los datos.
¿Es esta una conclusión sensata? ¿Entiendo mal mucho? ¿Me estoy perdiendo algo más?
Me doy cuenta de que existe una consideración de sobrecarga con cada archivo, pero no sé cuán grande es el impacto. Si tuviera que consolidar los back-ends, también existe el beneficio potencial de poder permitir que Access maneje la integridad referencial para las eliminaciones en cascada, etc., en lugar de codificar para eso ...
Apreciaría cualquier pensamiento o crítica (razonablemente válida).
Este es un malentendido común:
MS Access tiene que extraer todo el archivo de la base de datos a la computadora local para realizar consultas o actualizaciones
Considera esta consulta:
SELECT first_name, last_name
FROM Employees
WHERE EmpID = 27;
Si se indexa EmpID, el motor de la base de datos leerá lo suficiente del índice para encontrar las filas de la tabla que coincidan, luego leerá las filas correspondientes. Si el índice incluye una restricción única (por ejemplo, EmpID es la clave principal), la lectura será más rápida. El motor de base de datos no lee toda la tabla, ni siquiera todo el índice.
Sin un índice en EmpID, el motor haría un escaneo completo de la tabla Empleados, lo que significa que tendría que leer cada fila de la tabla para determinar qué valores de EmpID coinciden.
Pero de cualquier manera, el motor no necesita leer toda la base de datos ... Las tablas de Clientes, Inventario, Ventas, etc. ... no tiene ninguna razón para leer toda esa información.
Tiene razón en que hay gastos generales para las conexiones a los archivos de la base de datos de fondo. El motor debe administrar un archivo de bloqueo para cada base de datos. No sé la magnitud de ese impacto. Si fuera yo, crearía una nueva base de datos back-end e importaría las tablas de las demás. Luego haga una copia del front-end y vuelva a vincular a las tablas de fondo. Eso le daría la oportunidad de examinar directamente el impacto en el rendimiento.
Me parece que la integridad relacional debería ser un argumento sólido para consolidar las tablas en un solo back-end.
En cuanto al bloqueo, nunca debería necesitar bloquear toda la base de datos back-end para las operaciones DML de rutina (INSERTAR, ACTUALIZAR, ELIMINAR). El motor base de base de datos admite un bloqueo más granular. También bloqueo pesimista frente a oportunista: si el bloqueo se produce una vez que comienza a editar una fila o se aplaza hasta que se guarde la fila modificada.
En realidad, la "red lenta" podría ser la mayor preocupación si lento significa una red inalámbrica. El acceso solo es seguro en una LAN cableada.
Editar : El acceso no es apropiado para un entorno de red WAN. Vea esta página por Albert D. Kallal.