sql >> Base de Datos >  >> RDS >> Mysql

Programa de base de datos de reservas de citas médicas de java (mysql) ... tener problemas para diseñar el esquema de citas

La fecha y hora es un valor

Los valores de fecha y hora casi siempre se rastrean en el software como valores únicos. Técnicamente, se representan internamente como un recuento de segundos/milisegundos/microsegundos/nanosegundos desde una época .

Es posible que desee presentar una fecha y una hora por separado en la interfaz de usuario, pero no internamente.

Además, es casi seguro que debería estar pensando en las zonas horarias. Los programadores ingenuos a menudo piensan que pueden ignorar las zonas horarias, pero es casi seguro que eso les causará angustia más adelante.

Comprenda el manejo de fecha y hora de su base de datos

Diferentes bases de datos manejan la fecha y la hora de manera diferente. Absolutamente crucial que lea los documentos, juegue, experimente y aprenda exactamente cómo funciona su base de datos.

Postgres tiene un manejo excelente y sensato de fecha y hora. Incluso si usa otra base de datos, consulte la excelente documentación de Postgres en date- tipos de datos de tiempo y funciones de fecha y hora (comandos) para obtener información sobre los diversos problemas y sobre lo que define el estándar SQL frente a lo peculiar de su base de datos.

Almacenar globalmente, presentar localmente

Date-Time es un problema sorprendentemente resbaladizo y complicado. Una clave para controlar el problema es trabajar en UTC . Almacene sus valores de fecha y hora en la base de datos (o en archivos serializados o comunicaciones XML/JSON) en UTC. Escriba la mayor parte de su lógica comercial en UTC, excepto cuando la zona horaria local sea importante, como definir "el comienzo de un nuevo día".

Cuando se presente al usuario, use el formato ISO 8601 o localice su propia zona horaria (o la zona horaria que esperan). Esto sigue la idea básica de internacionalización/localización. Para los valores de texto, usa ciertas cadenas clave en su código. Tras la presentación en la interfaz de usuario, asigna esas cadenas internas a valores de texto localizados (traducidos) para la interfaz de usuario. Algunos con fecha y hora:UTC internamente, zona horaria local en la interfaz de usuario.

Una advertencia:es posible que desee también almacenar una fecha y hora local por el bien de la historia. Las reglas de las zonas horarias cambian con frecuencia y caprichosamente debido a los políticos y burócratas. La base de datos de zonas horarias de su software puede estar desactualizada. Por lo tanto, es posible que desee almacenar lo que usted o el usuario creían que era una determinada fecha y hora luego . Pero no confíe en ello; determinar y almacenar el valor UTC.

Consejo:Aprende a pensar y leer en 24 horas. Su vida como programador/depurador/administrador de sistemas será mucho más fácil y menos propensa a errores.

Joda-Time o java.time

Las clases java.util.Date y .Calendar incluidas con Java son notoriamente problemáticas. Evítales.

En su lugar, utilice Joda-Time o el nuevo paquete java.time integrado en Java 8 (inspirado en Joda-Time, definido por JSR 310).

Ambas bibliotecas usan formatos ISO 8601 como predeterminados, tanto para analizar como para generar cadenas.

ISO 8601

ISO 8601 es un estándar sensato que define cómo presentar valores de fecha y hora, zonas horarias y compensaciones, duraciones y períodos en formatos de texto específicos y no ambiguos. Estudia esa página de Wikipedia bien escrita.

Tenga en cuenta en particular lo que el estándar llama Durations . Un lapso de tiempo se define en este formato:PnYnMnDTnHnMnS donde P significa "Periodo", la T separa la parte de la fecha de la parte de la hora, y las otras partes opcionales son dígitos + letra. Una cita de media hora sería PT30M . Esto puede ser útil para usted, como para el campo "período_" que se ve en mi ERD abajo. En Joda-Time, la clase Period representa un lapso de tiempo mediante el seguimiento de sus meses, días, horas, etc., y sabe cómo analizar y generar cadenas en este formato.

Medio abierto

Puede optar por almacenar citas de dos maneras. Una forma es una fecha y hora de inicio y una duración (90 minutos, 20 minutos, etc.). Otra forma es registrar una fecha y hora de inicio y finalización. En este caso, el enfoque habitual y generalmente mejor se denomina "Medio abierto". Esto significa que el comienzo es inclusivo mientras que el final es exclusivo .

Por ejemplo, una cita de una hora en punto se ejecutaría de 11:00 a 12:00, lo que significa "comenzando a las 11 a. m. y terminando, pero sin incluir, el primer momento de la siguiente hora (mediodía)". La próxima cita será de 12:00 a 13:00.

Busque StackOverflow para "Half-open" para encontrar más discusión, ejemplos y diagramas.

Muchos a muchos

La relación entre Paciente y Médico es lo que llamamos Many-To-Many . Un médico atiende a muchos pacientes, y un paciente puede ver a más de uno de los médicos. Asegúrese de conocer las tablas Many-To-Many en el diseño de bases de datos relacionales. La solución siempre es agregar una tercera tabla, a veces llamada tabla "puente" que sirve como tabla secundaria para las otras dos tablas principales. En su caso, la Cita la mesa es la mesa puente.

Deberá saber cómo realizar uniones en una relación de muchos a muchos.

SQL directo

Si es nuevo en programación o en bases de datos relacionales, le sugiero que evite Hibernate. Realmente deberías tener una idea de lo que está pasando. Hibernate tiene algunos usos apropiados. Pero si cree que Hibernate va a hacer desaparecer mágicamente los problemas de la base de datos, se sentirá decepcionado.

Atributos

Los atributos dependen de usted. Dependen del problema empresarial (¿o de la tarea?) que esté tratando de resolver. Tienes los conceptos básicos correctos.

La programación de citas es un problema comercial muy difícil para el cual escribir software. Por ejemplo, ¿simplemente está grabando las citas que se están haciendo? ¿O está realizando un seguimiento de la disponibilidad de los médicos mediante la creación de intervalos de tiempo predefinidos y, de ser así, cómo maneja las excepciones y los cambios en el calendario de cada médico? Debe escribir requisitos y casos de uso muy específicos. Es muy fácil que las expectativas de los usuarios superen tus supuestos requisitos.

Esta es una vista simplista.