El contenido de un determinado campo de datos MySQL no se puede almacenar y el contenido de un determinado campo no se puede leer en la página.
Convención de nomenclatura de campos de tablas de bases de datos
Resumen: En el trabajo de investigación y desarrollo actual, a menudo hay problemas que afectan el progreso del desarrollo debido a tablas de base de datos irregulares y formatos de campo de tabla de base de datos. Cuando la tabla de base de datos original se utiliza en un desarrollo posterior, la legibilidad de la tabla de base de datos no es lo suficientemente alta , y las reglas del campo de la tabla no son lo suficientemente altas. La unificación da como resultado la consulta de datos y una baja eficiencia en el uso de datos. Por lo tanto, es necesario clasificar un conjunto de convenciones de nomenclatura de campos de tablas de base de datos adecuadas para resolver y optimizar estos problemas.
Este artículo es un documento estandarizado que incluye nombres de bases de datos, nombres de tablas de bases de datos, nombres de campos de tablas de bases de datos y codificación en lenguaje SQL. Está organizado y modificado para los problemas y errores comunes que son fáciles de ocurrir en la investigación y el desarrollo, y está relacionado con la base de datos. -investigación y desarrollo relacionados en el futuro Esté preparado para el trabajo.
Uno, la convención de nomenclatura de bases de datos
Use 26 letras en inglés (distingue entre mayúsculas y minúsculas) y números naturales del 0 al 9 (a menudo no es necesario) más un guión bajo ' ', el nombre es conciso y claro, varias palabras están separadas por guiones bajos ' ', un proyecto es una base de datos, varios proyectos son cuidado Usa la misma base de datos
En segundo lugar, la convención de nomenclatura de la tabla de la base de datos
2.1 Convención de nomenclatura de la hoja de datos
(1) Está compuesto por 26 letras en inglés (distingue entre mayúsculas y minúsculas) y números naturales del 0 al 9 (a menudo no es necesario) más un guión bajo ' ', el nombre es conciso y claro, y varias palabras están separadas por un guión bajo ' '
(2) Nombre todo en minúsculas, no en mayúsculas
(3) Está prohibido utilizar palabras clave de la base de datos, como nombre, hora, fecha y hora, contraseña, etc.
(4) El nombre de la tabla no debe ser demasiado largo (generalmente no más de tres palabras en inglés)
(5) El nombre de la tabla generalmente usa sustantivos o frases de verbo-objeto
(6) Use la forma singular para expresar el nombre, por ejemplo, use empleado en lugar de empleados
El nombre de la tabla detallada es: el nombre de la tabla principal + caracteres dtl (abreviatura del detalle)
Por ejemplo: el nombre de la orden de compra es: po_order, luego la tabla detallada de la orden de compra es: po_orderdtl
(7) La tabla debe llenarse con información de descripción (cuando se usa la declaración SQL para construir la tabla)
2.2 Convención de nomenclatura
①Ejemplo de módulo_ + punto de función: alllive_log alllive_category
②Ejemplo de punto de función: mensaje en vivo
③Ejemplo de tabla general: all_user
2.3 Ejemplos de naming a optimizar
①Redundancia:
Ejemplo de error: yy_alllive_video_recomment yy_alllive_open_close_log
Nota: Elimine el nombre del proyecto, simplifique la longitud del nombre de la tabla, vaya a "yy_"
②Existen diferencias en la denominación de tablas de la misma categoría y mala gestión
Ejemplo de error: yy_all_live_category yy_alllive_comment_user
Nota: Elimina el nombre del proyecto, unifica las reglas de nomenclatura, todo comienza con "yy_alllive_"
③El formato de nomenclatura es diferente
Ejemplos de errores: yy_showfriend yy_user_getpoints yy_live_program_get
Descripción: Elimina nombres de elementos, unifica reglas de nomenclatura, separa verbos y frases de objetos y unifica la secuencia lógica de verbos y objetos.
Tres, convención de nomenclatura de campos de base de datos
3.1 Convención de nomenclatura de campos
(1) Está compuesto por 26 letras en inglés (distingue entre mayúsculas y minúsculas) y números naturales del 0 al 9 (a menudo no es necesario) más un guión bajo ' ', el nombre es conciso y claro, y varias palabras están separadas por un guión bajo ' '
(2) Nombre todo en minúsculas, no en mayúsculas
(3) La información descriptiva debe completarse en el campo.
(4) Está prohibido utilizar palabras clave de la base de datos, como nombre, hora, contraseña de fecha y hora, etc.
(5) Los nombres de campo generalmente usan sustantivos o frases de verbo-objeto
(6) El nombre del campo utilizado debe ser fácil de entender, generalmente no más de tres palabras en inglés.
(7) Al nombrar las columnas de la tabla, no repita el nombre de la tabla
Por ejemplo, evite usar un campo llamado employee_lastname en una tabla llamada employee
(8) No incluya el tipo de datos en el nombre de la columna
(9) Utilice nombres completos para nombrar los campos y sin abreviaturas
3.2 convenio de nomenclatura
① Ejemplo de sustantivo: user_id user_name sex
②Ejemplo de frase verbal: is_friend is_good
3.3 Ejemplos de naming a optimizar
①Las reglas de capitalización no son uniformes
Ejemplo incorrecto: user_id houseID
Nota: use reglas uniformes y modifíquelas a "user_id" y "house_id"
②Las reglas subrayadas no son uniformes
Ejemplo incorrecto: nombre de usuario ID de usuario isfriend is good
Nota: Use guiones bajos para clasificar, mejorar la reproducibilidad y facilitar la administración, y modificarlo a "nombre_usuario", "id_usuario", "es_amigo" y "es_bueno".
③El campo no está claro
Ejemplo de error: uid pid
Nota: use el nombre completo para mejorar la legibilidad y modifíquelo a "user_id" y "person_id"
3.4 Especificación del tipo de campo
(1) Al diseñar todos los campos, excepto los siguientes tipos de datos: marca de tiempo, imagen, fecha y hora, pequeña fecha y hora, identificador único, binario, sql_variant, binary, varbinary, deben tener valores predeterminados. El valor predeterminado del tipo de carácter es una cadena vacía de caracteres., El valor predeterminado del tipo numérico es el valor 0, y el valor predeterminado del tipo lógico es el valor 0
(2) En todos los tipos lógicos del sistema, el valor 0 se representa como "falso" y el valor 1 se representa como "verdadero". Los campos de tipo datetime y smalldatetime no tienen valores predeterminados y deben ser NULL.
(3) Utilice el menor espacio de almacenamiento posible para almacenar los datos de un campo
No use varchar, char cuando use int,
No use varchar (16) en lugar de varchar (256)
La dirección IP usa el tipo int
El tipo de longitud fija es mejor usar char, por ejemplo: código postal (código postal)
No use smallint si puede usar tinyint, int
Es mejor darle a cada campo un valor predeterminado, preferiblemente no nulo
(4) Utilice los tipos de campo adecuados para ahorrar espacio
Los caracteres se convierten en números (la mejor conversión que se puede convertir, lo que también ahorra espacio y mejora el rendimiento de las consultas)
Evite el uso de campos NULL (los campos NULL son difíciles de consultar y optimizar, los índices de campo NULL requieren espacio adicional y los índices compuestos en los campos NULL no son válidos)
Use menos tipo de texto (intente usar varchar en lugar de campo de texto)
3.5 Descripción canónica de cada campo de la base de datos
(1) Intente cumplir con los estándares de la tercera forma normal (3NF)
表内的每一个值只能被表达一次
表内的每一行都应当被唯一的标示
表内不应该存储依赖于其他键的非键信息
(2) Si el campo está realmente asociado con las palabras clave de otras tablas y no está diseñado como una referencia de clave externa, es necesario crear un índice.
(3) Si el campo está relacionado con el campo de otras tablas, es necesario crear un índice
(4) Si es necesario buscar en el campo otras condiciones que no sean una consulta difusa, es necesario crear un índice.
(5) A excepción de la clave principal para permitir la creación de un índice de clúster, los índices de otros campos deben ser índices no agrupados.
Cuatro estándares de codificación de lenguaje SQL
4.1 Capitalización
(1) Todas las palabras clave deben estar en mayúscula, como: INSERT, UPDATE, DELETE, SELECT y sus cláusulas, IF …… ELSE, CASE, DECLARE, etc.
(2) Todas las funciones y sus parámetros, excepto las variables de usuario, deben estar en mayúscula
(3) El tipo de datos utilizado al definir variables debe estar en minúsculas
4.2 Notas
Los comentarios se pueden incluir en el procesamiento por lotes. La inclusión de comentarios descriptivos en los desencadenadores y los procedimientos almacenados aumentará en gran medida la legibilidad y el mantenimiento del texto. Esta especificación recomienda:
(1) Los comentarios están principalmente en inglés. En la aplicación real, se encuentra que la versión de la declaración SQL con comentarios en chino no está disponible en el entorno inglés. Para evitar algunos errores anormales durante la ejecución de versiones posteriores, se recomienda usar comentarios en inglés
(2) El comentario debe ser lo más detallado y completo posible. Antes de crear cada objeto de datos, se debe describir en detalle la función y el propósito del objeto. Se debe explicar el significado de los parámetros entrantes. Si se determina el rango de valores, también deben explicarse juntos. Para las variables con significados específicos (como las variables booleanas), se debe dar el significado de cada valor
(3) Sintaxis de comentario: comentario de una línea, comentario de varias líneas
Comentario de una sola línea: hay dos guiones (-) antes del comentario, que se pueden usar para variables y cláusulas condicionales.
Comentarios multilínea: El contenido entre los símbolos es el contenido del comentario. Se recomienda utilizar este tipo de comentario para una operación completa.
(4) Las notas son concisas y la descripción debe ser clara.
(5) Comentario de función:
Al escribir texto de función, como disparadores, procedimientos almacenados y otros objetos de datos, debe agregar los comentarios adecuados a cada función. Los comentarios son principalmente comentarios de varias líneas y la estructura principal es la siguiente:
CREAR PROCEDIMIENTO sp_xxx
Lo anterior se reenvía desde https://www.cnblogs.com/isme-zjh/p/11720160.html
Regalar una castaña
Dar un poco de castaña (el contenido del campo correspondiente en la parte posterior no se puede almacenar)
El nombre del campo es domain_certificate_creditCard. El contenido de este campo se puede almacenar en la base de datos, pero el contenido de este campo no se puede almacenar en el backend.
Cambie el campo domain_certificate_creditCard a domain_certificate_credit_card, y la base de datos se puede almacenar normalmente.
private String domain_certificate_credit_card;//域名证书（信用卡）
Dar otra pequeña castaña (la parte delantera no puede leer el contenido del campo correspondiente)
El campo denominado CS_Email_id se puede almacenar en la base de datos, pero el contenido de este campo no se puede recuperar cuando se toma el valor ajax en la página de inicio.
Google Chrome abrió las herramientas del desarrollador (F12) y descubrió que había contenido en este campo. No pude comprobar y volver a comprobar y descubrí que el campo correspondiente al json devuelto por las herramientas del desarrollador es CS_Email_id en minúscula, que es cs_email_id.
Se sospecha que lo anterior debe configurarse o es un motivo de codificación. Si tiene una buena solución, deje un comentario en el área de comentarios. Dame un pulgar hacia arriba, gracias.