Diseño de estructura de base de datos para grandes volúmenes de datos y alto acceso concurrente
Si no se puede diseñar un modelo de base de datos razonable, no solo aumentará la dificultad de programación y mantenimiento de los segmentos de programas de cliente y servidor, sino que también afectará la funcionamiento real del sistema. Por lo tanto, es necesario diseñar un modelo de base de datos completo antes de la implementación del sistema.
En la etapa de análisis y diseño del sistema, debido a la pequeña cantidad de datos, la carga es baja. A menudo solo prestamos atención a la implementación de funciones, pero es difícil notar los puntos débiles en el rendimiento. No es hasta que el sistema se pone en funcionamiento real durante un período de tiempo que encontramos que el rendimiento del sistema está disminuyendo. En este momento, tenemos que dedicar más tiempo a considerar mejorar el rendimiento del sistema. Se requieren recursos humanos y materiales, y todo el sistema inevitablemente se convierte en un proyecto de retoque.
Por lo tanto, al considerar el proceso de todo el sistema, debemos considerar si nuestro sistema encontrará situaciones extremas bajo condiciones de alta concurrencia y gran acceso a datos. (Por ejemplo: el 16 de julio, los datos en el sistema estadístico externo eran anormales. Una gran cantidad de acceso simultáneo a los datos hizo que el tiempo de respuesta de la base de datos no pudiera mantenerse al día con la velocidad de actualización de los datos. La situación específica es: en la fecha Umbral (00:00:00), determine si hay datos en la base de datos. Si no hay ningún registro de la fecha actual, inserte un registro de la fecha actual. Cuando el volumen de acceso simultáneo sea bajo, no habrá ningún problema. Sin embargo, cuando el volumen de acceso en el punto crítico de la fecha es bastante grande, al hacer este juicio, habrá situaciones en las que se cumplirán varias condiciones. En este momento, se insertarán varios registros de la fecha actual en la base de datos. errores de datos (Error de datos). Después de determinar el modelo de la base de datos, es necesario dibujar un diagrama de flujo de datos en el sistema para analizar posibles problemas.
Para garantizar la coherencia e integridad de la base de datos. , demasiadas asociaciones entre tablas a menudo están diseñadas para reducir la redundancia de datos tanto como sea posible (por ejemplo, áreas en tablas de usuario, podemos almacenar otra tabla de áreas) Si la redundancia de datos es baja, la integridad de los datos es fácil. para garantizar, lo que mejora la velocidad del rendimiento de los datos, garantiza la integridad de los datos y expresa claramente la relación entre los elementos de datos. El rendimiento de las consultas asociadas entre varias tablas (especialmente tablas de datos grandes) se reducirá y también aumentará. Por lo tanto, es necesario hacer concesiones durante el diseño físico y determinar la asociación en función de las reglas comerciales. El tamaño de los datos de la tabla y la frecuencia de acceso de los elementos de datos con consultas relacionadas frecuentes. El diseño de la redundancia de datos debe mejorarse adecuadamente, pero se debe aumentar la operación de consultas de conexión entre tablas. Esto también es para mejorar el tiempo de respuesta del sistema, lo cual es razonable. Los diseñadores también deben considerar el tipo y la frecuencia. de las operaciones del sistema durante la fase de diseño. Además, es mejor no utilizar campos de atributos de incremento automático como claves principales asociadas con tablas secundarias. No es conveniente para la migración del sistema y la recuperación de datos. Se perderá la relación de mapeo del sistema estadístico. (******************)
La tabla original debe estar disponible para la reconstrucción de la tabla separada. El beneficio de utilizar esta disposición es que garantiza que no. Se introducen columnas redundantes en la tabla separada y que todas las estructuras de tabla que cree tengan el tamaño que realmente necesitan. Es una buena idea aplicar esta disposición, no es necesario utilizarla a menos que la cantidad de datos procesados sea muy grande. (por ejemplo, en un sistema de pases, puedo usar USERID, USERNAME, USERPASSWORD como una tabla separada y luego usar USERID como clave externa para otras tablas)
Cuestiones específicas a tener en cuenta en el diseño de tablas:
1. La longitud de la fila de datos no debe exceder los 8020 bytes. Si excede la longitud de la página física, dichos datos ocuparán dos filas, lo que provocará la fragmentación del almacenamiento y reducirá la eficiencia de la consulta. >
2. Para los campos que pueden usar tipos numéricos, intente elegir tipos numéricos en lugar de tipos de cadenas (números de teléfono). Esto reducirá el rendimiento de las consultas y las conexiones y aumentará la cantidad de consultas. el motor necesita comparar cada carácter de la cadena devuelta uno por uno al procesar la consulta y la conexión, y solo una comparación es suficiente para los tipos numéricos.
3. Tanto el tipo de carácter inmutable char como el tipo de carácter variable varchar tienen 8000 bytes. La consulta char es rápida pero consume espacio de almacenamiento. La consulta varchar es relativamente lenta pero ahorra espacio de almacenamiento.
Puede elegir con flexibilidad al diseñar campos. Para campos con longitudes cambiantes, como nombre de usuario y contraseña, puede elegir CHAR. Para campos con longitudes cambiantes, como comentarios, puede elegir VARCHAR.
4. La longitud del campo debe acortarse tanto como sea posible bajo la premisa de satisfacer las necesidades tanto como sea posible. Esto no solo puede mejorar la eficiencia de la consulta, sino también reducir el recurso. consumo a la hora de establecer el índice.
5. La relación entre la tabla básica y sus campos debe intentar cumplir con la tercera forma normal. Sin embargo, un diseño de base de datos que satisfaga la tercera forma normal a menudo no es el diseño óptimo. Para mejorar la eficiencia operativa de la base de datos, a menudo es necesario reducir el estándar del paradigma: aumentar adecuadamente la redundancia para lograr el propósito de intercambiar espacio por tiempo.
6. Si existe una relación de muchos a muchos entre dos entidades, esta relación debe eliminarse. El método de eliminación consiste en agregar una tercera entidad entre las dos entidades. De esta manera, la relación original de uno a muchos se convierte en dos relaciones de uno a muchos. Los atributos de las dos entidades originales se asignarán razonablemente a las tres entidades. La tercera entidad aquí es esencialmente una relación más compleja, equivalente a una tabla básica. En general, las herramientas de diseño de bases de datos no reconocen relaciones de muchos a muchos, pero pueden manejar relaciones de muchos a muchos.
7. El método PK del valor de clave principal es una herramienta de conexión entre tablas para programadores. Puede ser una cadena numérica no física, que el programa agrega automáticamente en 1. También puede ser un nombre de campo físicamente significativo o una combinación de nombres de campo. Pero lo primero es mejor que lo segundo. Cuando PK es una combinación de nombres de campos, se recomienda no tener demasiados campos. Si hay demasiados campos, el índice no solo ocupará mucho espacio, sino que también será lento.
8. La duplicación de claves primarias y claves externas en varias tablas no constituye redundancia de datos. De hecho, muchas personas aún no lo tienen claro. ¡La duplicación de campos no clave es redundancia de datos! Y es redundancia de bajo nivel, es decir, redundancia repetida. La redundancia de alto nivel no es la recurrencia de un campo, sino la aparición derivada de un campo.
〖Ejemplo 4〗: En los tres campos de "precio unitario, cantidad y monto" del producto, "monto" se deriva del "precio unitario" multiplicado por "cantidad". La "cantidad" se deriva, es redundante, es redundancia de alto nivel. El propósito de la redundancia es aumentar la velocidad de procesamiento. Sólo la redundancia de bajo nivel aumenta la inconsistencia de los datos porque los mismos datos pueden ingresarse varias veces desde diferentes momentos, ubicaciones y roles. Por lo tanto, defendemos la redundancia de alto nivel (redundancia derivada) y nos oponemos a la redundancia de bajo nivel (redundancia por duplicación).
9. La tabla intermedia es una tabla que almacena datos estadísticos y está diseñada para almacenes de datos, informes de salida o resultados de consultas. A veces no hay claves primarias ni claves externas (excepto los almacenes de datos). Las tablas temporales están diseñadas por programadores individuales para almacenar registros temporales para uso personal. El DBA mantiene las tablas básicas y las tablas intermedias, y los propios programadores mantienen automáticamente las tablas temporales.
10. El método para evitar que se parchee el diseño de la base de datos son los "Tres pocos principios"
(1) Cuanto menor sea el número de tablas en la base de datos, mejor. Solo una pequeña cantidad de tablas pueden mostrar que el diagrama E-R del sistema tiene poco refinamiento, elimina entidades repetitivas y redundantes, forma un mundo objetivo altamente abstracto, logra la integración de datos del sistema y evita parches de diseño;
(2) Cuanto menor sea el número de campos de clave principal en una tabla combinada, mejor. Debido a que la función de la clave principal es crear un índice para la clave principal y crear una clave externa para la subtabla, cuanto menor sea el número de campos de clave principal en la tabla combinada, mejor, lo que no solo ahorra tiempo de ejecución. , pero también ahorra espacio de almacenamiento del índice;
(3) Cuantos menos campos haya en una tabla, mejor. Solo una pequeña cantidad de campos puede significar que no hay datos duplicados en el sistema y que hay muy poca redundancia de datos. Más importante aún, se insta a los lectores a aprender a "convertir columnas en filas" para evitar que los campos de la subtabla. siendo arrastrado a la tabla principal quedan muchos campos vacíos en la tabla. La llamada "columna a fila" consiste en extraer parte del contenido de la tabla principal y crear una subtabla separada. Este método es muy simple, pero algunas personas simplemente no están acostumbradas, no lo adoptan y no lo implementan.
Un principio práctico del diseño de bases de datos es encontrar el equilibrio adecuado entre redundancia de datos y velocidad de procesamiento. "Tres Jóvenes Maestros" es un concepto general y un punto de vista integral, y un determinado principio no puede verse de forma aislada. Los principios son relativos, no absolutos. El principio de "tres más" es definitivamente incorrecto. Imagínese: si cubre un sistema con las mismas funciones, un diagrama E-R de cien entidades (*** mil atributos) definitivamente será mucho mejor que un diagrama E-R de doscientas entidades (*** dos mil atributos).
Defender el principio de "tres menos" es decirle a los lectores que aprendan a utilizar la tecnología de diseño de bases de datos para la integración sistemática de datos. Los pasos de la integración de datos son integrar el sistema de archivos en la base de datos de la aplicación, integrar la base de datos de la aplicación en la base de datos del tema e integrar la base de datos del tema en la base de datos de integración global. Cuanto mayor sea el grado de integración, mayor será la accesibilidad y el disfrute de los datos, menor será el fenómeno de las islas de información y menor será el número de entidades, claves primarias y atributos en el diagrama E-R global de todo el sistema de información empresarial.
El propósito de defender el principio de "tres menos" es evitar que los lectores utilicen tecnología de parcheo para agregar, eliminar o modificar continuamente la base de datos, convirtiendo la base de datos empresarial en un "montón de basura" o una "habitación miscelánea". de tablas de bases de datos diseñadas aleatoriamente ". El "gran patio" finalmente resultó en que las tablas básicas, tablas de códigos, tablas intermedias y tablas temporales de la base de datos se desorganizaran y fueran innumerables, lo que provocó que los sistemas de información de empresas e instituciones no pudieran mantenerse y se paralizaran.
Cualquiera puede implementar el principio de "tres más", pero el principio del "método de parche" del diseño de bases de datos está distorsionado. El principio "Tres menos" es el principio de menos pero mejor. Requiere habilidades muy altas y un nivel artístico en el diseño de bases de datos. No todos pueden hacerlo, porque este principio es la base teórica para eliminar el "método de parche" en el diseño de bases de datos. .
11. Bajo las condiciones dadas de hardware y software del sistema, el método para mejorar la eficiencia operativa del sistema de base de datos es:
(1) En el diseño físico de la base de datos, reduzca el paradigma y aumente la redundancia, utilice menos desencadenantes y más procedimientos almacenados.
(2) Cuando el cálculo es muy complejo y el número de registros es muy grande (por ejemplo, 10 millones), el cálculo complejo primero debe calcularse y procesarse fuera de la base de datos utilizando un sistema de archivos o programación. idioma, y finalmente Ingrese a la base de datos y agréguela a la tabla.
(3) Si se descubre que hay demasiados registros en la tabla, por ejemplo, más de 10 millones, entonces la tabla debe dividirse horizontalmente. El método de partición horizontal consiste en dividir horizontalmente los registros de la tabla en dos tablas, utilizando el valor PK de la clave principal de la tabla como límite. Si se descubre que la tabla tiene demasiados campos, por ejemplo, más de 80 campos, la tabla se dividirá verticalmente, dividiendo la tabla original en dos.
(4) Optimización del sistema de gestión de bases de datos DBMS, es decir, optimización de varios parámetros del sistema, como el número de buffers.
(5) Al programar en lenguaje SQL orientado a datos, intente utilizar algoritmos de optimización.
En resumen, para mejorar la eficiencia operativa de la base de datos, se deben realizar esfuerzos simultáneamente desde tres niveles: optimización a nivel del sistema de base de datos, optimización a nivel de diseño de base de datos y optimización a nivel de implementación del programa.
Diseño de clave principal:
1. No se recomienda utilizar varios campos como clave principal. Aún es posible una sola tabla, pero habrá problemas con la asociación. El incremento de la clave principal es de alto rendimiento.
2. Generalmente, si hay dos claves externas, no se recomienda utilizar dos claves externas como enlace y el otro campo como clave principal. A menos que este registro no tenga una marca de desecho, siempre habrá un solo registro en la tabla para esta clave primaria conjunta.
3. En términos generales, una entidad no puede tener al mismo tiempo una clave primaria y una clave externa. En un diagrama E-R, una entidad en la sección hoja puede tener una clave principal definida o no (porque no tiene entidades secundarias), pero debe tener una clave externa (porque tiene una entidad principal).
El diseño de claves primarias y claves foráneas es muy importante en el diseño de la base de datos global. Cuando se completó el diseño de la base de datos global, un experto estadounidense en diseño de bases de datos dijo: "Claves, hay claves en todas partes y no hay nada más que claves. Esta es la voz de su experiencia en el diseño de bases de datos y también refleja su comprensión del núcleo". de sistemas de información (modelo de datos) es una idea muy abstracta. Porque: la clave principal es una entidad muy abstracta, y el emparejamiento de la clave principal y la clave externa muestra la conexión entre entidades.