1. Para el escenario comercial de consultas regulares del lado del cliente, puede considerar ponerlo en el servidor para consultar los resultados a la vez y luego notificar a cada cliente. Por ejemplo, cada cliente tiene una declaración de visualización de tiempo de espera, una declaración de visualización de mensajes, etc.
2. En el desarrollo real, si encuentra incompatibilidad con el sistema operativo y la versión de IE, puede considerar un modo de compatibilidad de shell más. Proporcione uso después de encapsular e implementar usted mismo.
3. Muchas sentencias SQL involucradas en el sistema están escritas en el código, lo que lleva a la necesidad de modificar el programa de servicio empresarial correspondiente cada vez que se agrega un campo o se modifica una sentencia, lo que tiene un gran impacto y altos costos de desarrollo y mantenimiento. .
4. Cuando la instrucción SQL específica es compleja, puede deberse a un diseño de tabla poco razonable. Alguna lógica de configuración de la estructura de la tabla se puede optimizar aún más de acuerdo con el escenario comercial. Para optimizar la oración correspondiente.
5. Se recomienda utilizar la lógica de consulta de paginación y los controles correspondientes para lograrlo. El usuario cambia inconscientemente a la página siguiente para su visualización y procesamiento.
6. Otro contenido:
(1) Múltiples puntos de función comercial, mezclados, usan la misma declaración SQL para escribir, lo que da como resultado muchos campos de consulta y muchas tablas relacionadas.
(2) Para el mismo punto de función comercial, diferentes hospitales tendrán oraciones de consulta ligeramente diferentes, lo que conduce al aumento continuo de campos e inconvenientes en el mantenimiento.
Se recomiendan dos tipos de transformación:
(1) Por el motivo (1), cada declaración SQL se utiliza para confirmar si hay varios puntos de función empresarial. Si esta situación existe, debe dividirse y las condiciones de consulta se reorganizan para cada punto de función comercial., Mostrar campos, escribir múltiples declaraciones SQL.
(2) Por la razón (2), se deben realizar las siguientes transformaciones en los requisitos de consulta:
(a) Es necesario encontrar un marco de capa de datos similar a MYBATIS en JAVA bajo C ++, y poner la declaración en el archivo de configuración para escribiendo. De esta manera, no es necesario cambiar el código y se pueden configurar diferentes sentencias SQL para el mismo punto de función comercial de cada hospital, lo que reduce la dificultad de mantenimiento.
(B) Además de configurar diferentes sentencias SQL para el mismo punto de función, también es necesario asegurarse de que el título del resultado de la consulta se pueda obtener dinámicamente de la configuración, de modo que se pueda configurar el resultado de la consulta.
(3) Transformación de paginación:
(1) Desarrolle un método de paginación unificado en segundo plano. Por lo general, el marco proporcionará al menos dos interfaces para consulta por queryByPage (consulta de paginación) y consulta (consulta general, sin paginación), por supuesto, de acuerdo con Participar diferentes parámetros de entrada y salida, habrá múltiples métodos de consulta de este tipo.
(2) La recepción proporciona un control de paginación independiente, o un control de tabla con función de paginación, y al mismo tiempo determina los parámetros de interfaz involucrados en la paginación con el servicio en segundo plano, como el número total de registros, el número de registros por página, etc., para facilitar la determinación de los parámetros del método de paginación en segundo plano.