¿Cuáles son los diseños comunes de sistemas de bases de datos ERP a gran escala (diseño de sistema ERP)?
La razón principal para utilizar el crecimiento propio es el rendimiento.
Los primeros sistemas de bases de datos solían utilizar ciertos números, como números de identificación, números de empresa, etc., como tablas de bases de datos.
Sin embargo, pronto todos descubrieron las desventajas
Por ejemplo, en los primeros sistemas de gestión hospitalaria, el número de identificación se usaba como lista de pacientes
Sin embargo, en primer lugar, no todos tienen una tarjeta de identificación; en segundo lugar, para los pacientes del extranjero, los números de identificación de los pacientes de diferentes países pueden no ser los mismos.
Por lo tanto, usar el número de identificación como formulario del paciente es un muy mal diseño.
Teniendo en cuenta que ningún médico o enfermera recordará deliberadamente estos números, es un mejor diseño utilizar el incremento automático.
El número de la empresa utiliza un método de codificación específico, que también es una base de datos temprana. Prácticas comunes en el sistema
Sus deficiencias también son obvias: es fácil tener problemas de software como el error del milenio, porque el número de dígitos diseñados cuando se diseñó originalmente la tabla de la base de datos era demasiado corto, lo que provocó que el sistema no funcionara. capaz de cumplir con los requisitos después de unos años de uso, sólo modificando el programa se puede seguir usando.
El problema es que cuando alguien diseña un sistema y estima cuántos dígitos de un determinado número tendrá. ser suficiente, existe el riesgo de predicciones inexactas
Con el autoincremento, no existe tal problema
Del mismo modo, nadie puede recordar estos números
Otra razón para usar el autoincremento son los problemas de rendimiento
Todos con algún conocimiento de programación saben que la comparación de tamaños numéricos es mucho más rápida que la comparación de tamaños de cadenas
El uso de autoincrementos puede mejorar enormemente la velocidad de búsqueda de datos
2
p>Evite el uso de claves primarias compuestas (compuestas) principalmente debido a problemas de rendimiento
La recuperación de datos requiere una gran cantidad de valores comparaciones, y comparar solo un campo es mucho más rápido que comparar varios campos
Usar uno solo también es muy beneficioso desde una perspectiva de programación, se puede escribir menos código para la condición donde en la declaración SQL, lo que significa que. la posibilidad de errores se reduce considerablemente
3
Clave primaria doble La clave primaria doble significa que la tabla de la base de datos tiene dos campos. Estos dos campos se convierten de forma independiente en claves primarias pero existen al mismo tiempo.
Las claves primarias duales en el sistema de base de datos se utilizaron por primera vez en el módulo de administración de usuarios
La fuente más antigua puede referirse al módulo de administración de usuarios del sistema operativo
La gestión de usuarios del sistema operativo tiene dos claves primarias independientes: la ID aleatoria generada automáticamente por el propio sistema operativo (Linux, Windows SID), loginid
p>Ambas ID deben ser únicas. si elimina la prueba de usuario y luego agrega una prueba de usuario, el SID es diferente y el ID de inicio de sesión es el mismo.
El objetivo principal de usar claves primarias duales es evitar la confusión causada al agregar el mismo inicio de sesión. ID
Por ejemplo, la gerente de ventas Hellen compartió el archivo localmente con el gerente general Peter. Un año después, el gerente general dejó la empresa y entró un empleado común, Peter. Ambos Peters usaron el mismo ID de inicio de sesión. loginid, si solo se usa loginid como clave principal para la administración de usuarios del sistema operativo, habrá una laguna: Peter, un empleado común, puede acceder a archivos que solo el gerente general puede ver
El. La identificación aleatoria generada automáticamente por el propio sistema operativo generalmente es utilizada por los siguientes usuarios. Es invisible
Las claves primarias dobles ahora se usan ampliamente en varios sistemas de bases de datos, no limitados a los sistemas de administración de usuarios
4
Con bases de datos fijas, para hacer frente a las necesidades cambiantes de los clientes, esto se basa principalmente en los siguientes factores: 4
1 El uso y mantenimiento normales de los sistemas EPR a gran escala requieren los fabricantes de software y sus numerosos socios proporcionan tecnología a los clientes servicios simultáneamente, incluida una gran cantidad de desarrollo secundario
Si los usuarios necesitan agregar nuevas tablas o bases de datos durante el uso normal del software, traerá dificultades al software fabricantes y sus numerosos socios
4
2 Necesidad de actualización de software
No hay software
El software permite a los clientes utilizarlo durante décadas o cientos de años sin necesidad de actualizar
Las actualizaciones de software a menudo implican cambios en la estructura de la tabla de la base de datos
Los fabricantes de software realizarán procedimientos adicionales para actualizar los datos de la base de datos de versiones anteriores del software a una nueva versión, pero es más difícil procesar las tablas generadas durante el uso del usuario
4
3 Necesidades de desarrollo de software
Utilice una base de datos fija. Las tablas de bases de datos son más fáciles de desarrollar y de desarrollo secundario
Para las tablas generadas durante el uso del usuario, cada vez que busca datos, primero debe buscar el nombre de la tabla y luego encontrar los datos. lo cual es más problemático
Por ejemplo, el primer software financiero de UF usaba Aess como base de datos y se creaba una nueva base de datos cada año
Pronto, tanto los usuarios como la UF descubrieron que múltiples fue difícil realizar el análisis de datos anuales
Así que este es un mal diseño
En ERP, es raro tener diferentes datos anuales separados por separado
Generalmente, el los datos de todos los años están en la misma tabla
Cuando empresas multinacionales o incluso empresas de un grupo entero utilizan el mismo sistema ERP, los datos de todas las empresas están juntos
La ventaja es que el análisis de datos es más fácil de realizar
La mayoría de los sistemas de bases de datos ahora pueden devolver una cierta cantidad de datos en un tiempo constante
Por ejemplo, en la base de datos Oracle, basándose en tomar 10 datos de 1 millón de datos, y al obtener 10 datos de 100 millones de datos, la diferencia de tiempo no es mucha
5
Evite recuperar una gran cantidad de datos de la base de datos a la vez Al recuperar una gran cantidad de datos, debe utilizar la paginación
Esta es básicamente la regla básica para el diseño de muchos sistemas de bases de datos actualmente
Hay muchos. tablas con más de 1 millón de datos en el sistema ERP Para cualquiera de las muchas tablas, recuperarlas todas a la vez hará que el servidor de la base de datos demore mucho tiempo y afectará la velocidad de respuesta del sistema de otros usuarios en línea.
En términos generales, en las operaciones diarias, en el caso de la visualización de paginación, la velocidad de respuesta del sistema es suficiente si los datos obtenidos cada vez están entre 1 y 100. Rápido, básicamente no hay una pausa particularmente larga en el cliente.
Este es un diseño ideal
Esta es también la razón por la cual los sistemas de bases de datos grandes a menudo usan ODBC, ADO y otros componentes de conexión de bases de datos comunes sin un componente específico de conexión de base de datos dedicado más rápido
Debido a que el cuello de botella del sistema radica en la base de datos (gran cantidad de datos), no en el cliente (el cliente solo recupera una pequeña cantidad de datos a la vez)
p>La paginación es muy común en los sistemas de bases de datos B/S
Los primeros sistemas de bases de datos a menudo usaban programas cliente para recuperar una gran cantidad de datos a la vez para almacenarlos en el buffer
Este ya no es el caso. Es particularmente necesario. Las razones principales son: 5
1 La tecnología de almacenamiento en búfer de la propia base de datos se ha mejorado enormemente.
La mayoría de las bases de datos almacenarán automáticamente en caché los datos de uso común en la memoria para mejorar el rendimiento.
5
2 La tecnología de almacenamiento en búfer de los componentes de conexión de la base de datos también está mejorando
Algunos componentes de conexión de la base de datos, incluido ADO, procesarán automáticamente conjuntos de resultados de datos (resultset) Almacenamiento en búfer, y el El efecto es bueno.
Los componentes de conexión de bases de datos relativamente nuevos, como Hibernate, también han agregado algunas funciones de almacenamiento en búfer del conjunto de resultados de datos.
Por supuesto, también hay algunos componentes de conexión de bases de datos que no almacenan en búfer. Almacenamiento en búfer de datos, como JDBCDriver, pero la situación debería cambiar en unos años
También hay algunos almacenamientos en búfer de datos menos exitosos, como los beans de entidad en EJB, el rendimiento no es satisfactorio y el rendimiento no es satisfactorio. Los datos del bean de entidad también se colocan en la memoria porque ocupa demasiada memoria.
En términos relativos, es relativamente difícil para los programadores actuales escribir búferes de datos del cliente que puedan exceder los dos efectos de almacenamiento en búfer anteriores.
p>