Mysql avanzado: especificaciones de diseño de bases de datos (2)

8. Modelo de sala de emergencias

Hay tres elementos en el modelo ER, a saber, entidades, atributos y relaciones.

Las entidades pueden considerarse objetos de datos, que a menudo corresponden a individuos reales en la vida real. En el modelo ER, está representado por un rectángulo. Las entidades se dividen en dos categorías, a saber, entidades fuertes y entidades débiles. Una entidad fuerte se refiere a una entidad que no depende de otras entidades; una entidad débil se refiere a una entidad que tiene una fuerte dependencia de otra entidad.

Los atributos se refieren a las características de las entidades. Por ejemplo, la dirección del supermercado, número de contacto, número de empleados, etc. Está representado por una elipse en el modelo ER.

La relación se refiere a la conexión entre entidades. Por ejemplo, cuando un supermercado vende productos a los clientes, se produce una conexión entre el supermercado y el cliente. Está representado por un diamante en el modelo ER.

Nota: Las entidades y propiedades no se distinguen fácilmente. He aquí un principio: debemos verlo desde la perspectiva del sistema en su conjunto: las entidades pueden existir de forma independiente y los atributos no se pueden dividir. Es decir, las propiedades no pueden contener otras propiedades.

8.1 Tipos de relaciones

Entre los tres elementos del modelo ER, las relaciones se pueden dividir en tres tipos: uno a uno, uno a muchos y muchos a muchos.
Uno a uno: se refiere a la relación uno a uno entre entidades. Por ejemplo, la relación entre un individuo y la información de la tarjeta de identificación es una relación uno a uno. Una persona solo puede tener una información de tarjeta de identificación, y la información de una tarjeta de identificación solo pertenece a una persona.

Uno a muchos: significa que la entidad de un lado puede corresponder a múltiples entidades del otro lado a través de relaciones. Por el contrario, a través de esta relación, la entidad del otro lado sólo puede corresponder a la entidad del único lado. Por ejemplo, creamos una nueva tabla de clases, cada clase tiene varios estudiantes y cada estudiante corresponde a una clase.Existe una relación de uno a muchos entre clases y estudiantes.

Muchos a muchos: significa que las entidades de ambos lados de la relación pueden corresponder a múltiples entidades de la otra parte a través de la relación. Por ejemplo, en el módulo de compras, la relación entre proveedores y supermercados es una relación de muchos a muchos: un proveedor puede abastecer a varios supermercados y un supermercado también puede comprar productos de varios proveedores. Otro ejemplo es un calendario de selección de cursos. Hay muchas materias, cada materia tiene muchos estudiantes para elegir y cada estudiante puede elegir varias materias. Esta es una relación de muchos a muchos.

8.2 Análisis de modelado

El modelo ER parece engorroso, pero es muy importante para nosotros controlar el proyecto general. Si solo está desarrollando una aplicación pequeña, quizás sea suficiente simplemente diseñar algunas tablas. Una vez que desee diseñar una aplicación de cierta escala, es muy importante establecer un modelo ER completo en la etapa inicial del proyecto. La esencia del desarrollo de proyectos de aplicaciones es en realidad el modelado.

El caso que diseñamos es un negocio de comercio electrónico. Dado que el negocio de comercio electrónico es demasiado grande y complejo, simplificamos el negocio, centrándonos en el significado de SKU (Unidad de almacenamiento) y SPU (Unidad de producto estándar). utilizó SKU directamente y no mencionó el concepto de SPU. Este diseño de negocio de comercio electrónico tiene un total de 8 entidades, como se muestra a continuación.

entidad de dirección
entidad de usuario
entidad de carrito de compras
Entidad de comentario
entidad de productos básicos
Entidad de clasificación de productos
entidad de orden
Entidad de detalles del pedido

Entre ellos, la clasificación de usuarios y productos son entidades sólidas porque no necesitan depender de ninguna otra entidad. Otras son entidades débiles, porque aunque pueden existir de forma independiente, todas dependen de la entidad usuaria, por lo que todas son entidades débiles. Conociendo estos elementos, podemos
crear un modelo ER para el negocio de comercio electrónico, como se muestra en la figura:

Insertar descripción de la imagen aquí

En esta figura, la relación agregada entre direcciones y usuarios es una relación de uno a muchos, mientras que los productos y los detalles del producto muestran una relación de uno a uno, y los productos y pedidos son una relación de muchos a muchos. Este modelo ER incluye 8 relaciones entre 8 entidades.

(1) Los usuarios pueden agregar múltiples direcciones en la plataforma de comercio electrónico;
(2) Los usuarios solo pueden tener un carrito de compras;
(3) Los usuarios pueden generar múltiples pedidos;
(4) Los usuarios pueden publicar múltiples comentarios;
(5) Un artículo A el producto puede tener múltiples comentarios;
(6) Cada categoría de producto contiene múltiples productos;
(7) Un pedido puede contener múltiples productos y un producto puede estar en múltiples pedidos.
(8) El pedido contiene varios detalles del pedido, porque un pedido puede contener diferentes tipos de productos.

8.3 Refinamiento del modelo ER

Con este modelo de ER, podemos entender el negocio del comercio electrónico en su conjunto. El modelo ER acaba de mostrar el marco del negocio del comercio electrónico, pero solo incluye ocho entidades: pedido, dirección, usuario, carrito de compras, comentario, producto, categoría de producto y detalles del pedido, y la relación entre ellos, que no puede ser mapeado todavía Tablas específicas y las relaciones entre tablas. Necesitamos agregar atributos y representarlos con elipses, para que el modelo ER que obtengamos sea más completo.

Por lo tanto, necesitamos diseñar más cada parte de este modelo ER, es decir, refinar los procesos comerciales específicos del comercio electrónico y luego integrarlos para formar un modelo ER completo. Esto puede ayudarnos a aclarar las ideas de diseño de la base de datos.

(1) La entidad de dirección incluye número de usuario, provincia, ciudad, región, destinatario, número de contacto y si es la dirección predeterminada.
(2) Las entidades de usuario incluyen número de usuario, nombre de usuario, apodo, contraseña de usuario, número de teléfono móvil, correo electrónico, avatar y nivel de usuario.
(3) La entidad del carrito de compras incluye el número del carrito de compras, el número de usuario, el número de producto, la cantidad de producto y la URL del archivo de imagen.
(4) La entidad del pedido incluye el número de pedido, el destinatario, el número de teléfono del destinatario, el monto total, el número de usuario, el método de pago, la dirección de envío y la hora del pedido.
(5) La entidad de detalles del pedido incluye el número de detalles del pedido, el número de pedido, el nombre del producto, el número de producto y la cantidad del producto.
(6) Las entidades del producto incluyen número de producto, precio, nombre del producto, número de clasificación, si está a la venta, especificaciones y color.
(7) La entidad de comentario incluye la identificación del comentario, el contenido del comentario, la hora del comentario, el número de usuario y el número de producto
(8) La entidad de clasificación de producto incluye el número de categoría, el nombre de la categoría y el número de categoría principal

Insertar descripción de la imagen aquí

8.4 Convertir el diagrama del modelo ER en una tabla de datos

Al dibujar el modelo ER, hemos aclarado la lógica de negocios. Ahora, estamos a punto de dar un paso muy importante: convertir el modelo ER dibujado en una tabla de datos específica. Los principios de conversión se presentan a continuación:

(1) Una entidad generalmente se convierte en una tabla de datos;
(2) Una relación de muchos a muchos generalmente se convierte en una tabla de datos; (
3) A menudo se convierte una relación de 1 a 1 o de 1 a muchos. convertidos a través del exterior de la tabla claves para expresar en lugar de diseñar una nueva tabla de datos
(4) Convertir atributos en campos de tabla.

De hecho, cualquier proyecto de aplicación basado en bases de datos puede completar el trabajo de diseño de la base de datos estableciendo primero un modelo ER y luego convirtiéndolo en una tabla de datos. El propósito no es crear un modelo de ER, sino ordenar la lógica empresarial y diseñar una base de datos excelente. Le sugiero que no modele por modelar, sino que utilice el proceso de creación de un modelo ER para organizar sus pensamientos de modo que crear un modelo ER tenga sentido.

Insertar descripción de la imagen aquí

9. Principios de diseño de tablas de datos.

Con base en el contenido anterior, se resumen los principios generales del diseño de tablas de datos: "Tres menos y uno más"

Cuanto menor sea el número de tablas de datos, mejor
Cuantos menos campos haya en la tabla de datos, mejor
Cuanto menor sea el número de campos de clave primaria conjuntos en la tabla de datos, mejor.
Cuantas más claves primarias y externas utilices, mejor

Nota: Este principio no es absoluto. A veces necesitamos sacrificar la redundancia de datos a cambio de la eficiencia del procesamiento de datos.

10. Sugerencias para escribir objetos de bases de datos.

10.1 Acerca de la biblioteca

[Obligatorio] El nombre de la biblioteca debe controlarse dentro de los 32 caracteres. Solo se pueden utilizar letras, números y guiones bajos en inglés. Se recomienda comenzar con una letra en inglés.
[Obligatorio] Todos los nombres de las bibliotecas en chino e inglés deben estar en minúsculas y las diferentes palabras deben estar separadas por guiones bajos. Debes ver el nombre y saber el significado.
[Obligatorio] El formato del nombre de la biblioteca: nombre del sistema empresarial_nombre del subsistema.
[Obligatorio] Está prohibido utilizar palabras clave (como tipo, orden, etc.) en el nombre de la biblioteca.
[Obligatorio] El juego de caracteres debe especificarse explícitamente al crear una base de datos y el juego de caracteres solo puede ser utf8 o utf8mb4. Ejemplo de SQL para crear una base de datos: CREAR BASE DE DATOS crm_fund CONJUNTO DE CARACTERES PREDETERMINADO 'utf8';
[Recomendación] Para que el programa se conecte a la cuenta de la base de datos, la cuenta de la base de datos debe usarse bajo el principio de privilegio mínimo y solo puede usarse bajo una base de datos, y no se permiten bases de datos cruzadas. En principio, la cuenta utilizada por el programa no puede tener permisos de eliminación.
[Recomendación] La biblioteca temporal tiene el prefijo tmp_ y la fecha es el sufijo; la biblioteca de respaldo tiene el prefijo bak_ y la fecha es el sufijo.

10.2 Acerca de tablas y columnas

[Obligatorio] Los nombres de tablas y columnas deben controlarse con un máximo de 32 caracteres. Los nombres de las tablas solo pueden usar letras, números y guiones bajos en inglés. Se recomienda comenzar con una letra en inglés.
[Obligatorio] Los nombres de las tablas y las columnas deben estar en minúsculas y las diferentes palabras deben estar separadas por guiones bajos. Debes ver el nombre y saber el significado.
[Obligatorio] El nombre de la tabla debe estar fuertemente relacionado con el nombre del módulo. Los nombres de las tablas en el mismo módulo deben usar un prefijo unificado tanto como sea posible. Por ejemplo: crm_fund_item
[Obligatorio] El juego de caracteres debe especificarse explícitamente como utf8 o utf8mb4 al crear una tabla.
[Obligatorio] Las palabras clave (como tipo, orden, etc.) están prohibidas en los nombres de tablas y columnas.
[Obligatorio] El tipo de motor de almacenamiento de tablas debe especificarse explícitamente al crear una tabla. Si no hay requisitos especiales, siempre será InnoDB.
[Obligatorio] Se requieren comentarios al crear una tabla.
[Obligatorio] La denominación de los campos debe utilizar palabras en inglés o abreviaturas que expresen el significado real siempre que sea posible. Por ejemplo: ID de empresa, no utilice corporación_id, sólo utilice corp_id.
[Obligatorio] El campo de tipo de valor booleano se denomina is_description. Por ejemplo, el campo en la tabla de miembros que indica si un miembro está habilitado se llama is_enabled.
[Obligatorio] Está prohibido almacenar datos binarios grandes, como imágenes y archivos, en la base de datos. Por lo general, el archivo es muy grande, lo que hace que el volumen de datos crezca rápidamente en un corto período de tiempo. Cuando la base de datos lee la base de datos, una gran cantidad
Por lo general, se realizan varias operaciones de IO aleatorias y el archivo es muy grande, lleva mucho tiempo. Generalmente almacenada en un servidor de archivos, la base de datos solo almacena información de la dirección del archivo.
[Sugerencia] Acerca de la clave primaria al crear una tabla: La tabla debe tener una clave primaria (1) Es obligatorio que la clave primaria sea id, el tipo sea int o bigint y sea auto_increment, se recomienda usar unsigned tipo sin firmar. (2) El campo que identifica el asunto de cada fila de la tabla no debe establecerse como clave principal, se recomienda configurarlo como otros campos como user_id, order_id, etc., y establecer un índice de clave único. Porque si se establece como la clave principal y el valor de la clave principal se inserta aleatoriamente, provocará divisiones de páginas internas de innodb y una gran cantidad de E/S aleatorias, lo que provocará una degradación del rendimiento.
[Recomendación] La tabla principal (como la tabla de usuarios) debe tener el campo de hora de creación (create_time) y el campo de hora de la última actualización (update_time) de los datos de la fila para facilitar la resolución de problemas.
[Recomendación] Todos los campos de la tabla deben tener atributos NO NULOS tanto como sea posible, y la empresa puede definir valores PREDETERMINADOS según sea necesario. Debido a que el uso de valores NULL causará problemas, como que cada fila ocupará espacio de almacenamiento adicional, la migración de datos es propensa a errores y los resultados del cálculo de la función agregada están sesgados.
[Recomendación] Todos los nombres y tipos de columnas que almacenan los mismos datos deben ser consistentes (generalmente se usan como columnas relacionadas, si los tipos de columnas relacionadas son inconsistentes durante la consulta, el tipo de datos se convertirá automáticamente de manera implícita, lo que hará que el índice en el columna deje de ser válida, lo que reducirá la eficiencia de la consulta).
[Recomendación] La tabla intermedia (o tabla temporal) se utiliza para conservar el conjunto de resultados intermedio y el nombre comienza con tmp_. La tabla de respaldo se utiliza para realizar una copia de seguridad o capturar una instantánea de la tabla de origen y su nombre comienza con bak_. Las mesas intermedias y de respaldo se limpian periódicamente.
[Demostración] Una declaración de creación de tablas más estandarizada:

CREATE TABLE user_info (
	`id` INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主键',
	`user_id` BIGINT ( 11 ) NOT NULL COMMENT '用户id',
	`username` VARCHAR ( 45 ) NOT NULL COMMENT '真实姓名',
	`email` VARCHAR ( 30 ) NOT NULL COMMENT '用户邮箱',
	`nickname` VARCHAR ( 45 ) NOT NULL COMMENT '昵称',
	`birthday` date NOT NULL COMMENT '生日',
	`sex` TINYINT ( 4 ) DEFAULT '0' COMMENT '性别',
	`short_introduce` VARCHAR ( 150 ) DEFAULT NULL COMMENT '一句话介绍自己，最多50个汉字',
	`user_resume` VARCHAR ( 300 ) NOT NULL COMMENT '用户提交的简历存放地址',
	`user_register_ip` INT NOT NULL COMMENT '用户注册时的源ip',
	`create_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
	`update_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
	`user_review_status` TINYINT NOT NULL COMMENT '用户资料审核状态，1为通过，2为审核中，3为未
	通过，4为还未提交审核',
	PRIMARY KEY ( `id` ),
	UNIQUE KEY `uniq_user_id` ( `user_id` ),
	KEY `idx_username` ( `username` ),
KEY `idx_create_time_status` ( `create_time`, `user_review_status` ) 
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '网站用户基本信息'

[Recomendación] Al crear tablas, puede utilizar herramientas de visualización. Esto garantiza que se puedan establecer todas las convenciones relacionadas con tablas y campos.

10.3 Acerca de los índices

[Obligatorio] La clave principal de la tabla InnoDB debe ser id int/bigint auto_increment y no se puede actualizar el valor de la clave principal.
[Obligatorio] Para las tablas del motor de almacenamiento InnoDB y MyISAM, el tipo de índice debe ser BTREE.
[Recomendación] El nombre de la clave principal comienza con pk_, la clave única comienza con uni_ o uk_ y el índice ordinario comienza con idx_. Utilice siempre el formato en minúsculas, con el nombre o abreviatura del campo como sufijo.
[Sugerencia] Para un nombre de columna compuesto de varias palabras, tome las primeras letras de las primeras palabras y agregue la última palabra para formar nombre_columna. Por ejemplo:
el índice de la tabla de muestra member_id: idx_sample_mid.
[Recomendación] El número de índices en una sola tabla no puede exceder de 6.
[Sugerencia] Al crear un índice, considere crear un índice conjunto y coloque primero el campo con la distinción más alta.
[Recomendación] En el SQL de JOIN de varias tablas, asegúrese de que la columna de conexión de la tabla controlada tenga un índice, de modo que la eficiencia de ejecución de JOIN sea la más alta.
[Recomendación] Al crear una tabla o agregar un índice, asegúrese de que no haya índices redundantes en las tablas. Por ejemplo: si la clave (a, b) ya existe en la tabla, la clave (a) es un índice redundante y debe eliminarse.

10.4 escritura SQL

[Obligatorio] La instrucción SELECT del terminal debe especificar un nombre de campo específico y está prohibido escribir *.
[Sugerencia] Especifique el nombre del campo específico en la instrucción de inserción en el terminal. No escriba INSERT INTO t1 VALUES(…).
[Recomendación] Excepto en el caso de tablas estáticas o tablas pequeñas (dentro de 100 filas), las declaraciones DML deben tener condiciones WHERE y utilizar la búsqueda de índice.
[Recomendación] INSERTAR EN...VALUES(XX),(XX),(XX)... El valor de XX aquí no debe exceder 5000. Aunque el valor es demasiado alto, se conectará rápidamente, pero provocará un retraso en la sincronización maestro-esclavo.
[Recomendación] No utilice UNION en la declaración SELECT. Se recomienda utilizar UNION ALL y el número de cláusulas UNION debe limitarse a 5.
[Recomendación] En un entorno en línea, JOIN de varias tablas no debe exceder las 5 tablas.
[Recomendación] Reduzca el uso de ORDER BY y comuníquese con la empresa sin ordenar sin ordenar, o coloque la clasificación en el programa. Las declaraciones ORDER BY, GROUP BY y DISTINCT consumen relativamente mucha CPU y los recursos de CPU de la base de datos son extremadamente valiosos.
[Recomendación] Para consultas que incluyen ORDER BY, GROUP BY y DISTINCT, mantenga el conjunto de resultados filtrado por la condición WHERE dentro de 1000 filas; de lo contrario, SQL será muy lento.
[Recomendación] Varias operaciones de modificación en una sola tabla se deben fusionar en una. La modificación de una tabla grande con más de 1 millón de filas debe ser revisada por el DBA y ejecutada durante el período de menor actividad del negocio. Se deben realizar varias modificaciones en una sola tabla. integrarse entre sí. Debido a que alterar la tabla generará bloqueos de tabla, todas las escrituras en la tabla se bloquearán durante este período, lo que puede tener un gran impacto en el negocio.
[Recomendación] Al operar datos en lotes, es necesario controlar el intervalo de procesamiento de transacciones y realizar la suspensión necesaria.
[Recomendación] La transacción no contiene más de 5 declaraciones SQL. Porque las transacciones demasiado largas causarán problemas como bloqueo de datos durante mucho tiempo, caché interno de MySQL, consumo excesivo de conexión, etc.
[Recomendación] La declaración de actualización en la transacción debe basarse en la clave principal o CLAVE ÚNICA tanto como sea posible, como ACTUALIZAR... DONDE id=XX; de lo contrario, se generarán bloqueos de espacio y el rango de bloqueo se expandirá internamente. , lo que resulta en un rendimiento reducido del sistema y un punto muerto.