Data-Hora é um valor
Os valores de data e hora são quase sempre rastreados no software como valores únicos. Tecnicamente, eles são representados internamente como uma contagem de segundos/milissegundos/microssegundos/nanossegundos desde uma época .
Você pode querer apresentar uma data e uma hora separadamente na interface do usuário, mas não internamente.
Além disso, você quase certamente deve estar pensando em fusos horários. Programadores ingênuos geralmente pensam que podem ignorar os fusos horários, mas é quase certo que isso causará angústia mais tarde.
Entenda o tratamento de data-hora do seu banco de dados
Bancos de dados diferentes lidam com data e hora de maneira diferente. É absolutamente crucial que você leia os documentos, brinque, experimente e aprenda exatamente como seu banco de dados funciona.
Postgres tem um tratamento excelente e sensato de data-hora. Mesmo que você use outro banco de dados, consulte a excelente documentação do Postgres em date- tipos de dados de tempo e funções de data e hora (comandos) para aprender sobre as diversas questões e sobre o que é definido pelo padrão SQL versus peculiar ao seu banco de dados.
Armazenar globalmente, apresentar localmente
Date-Time é um problema surpreendentemente escorregadio e complicado. Uma chave para controlar o problema é trabalhar em UTC . Armazene seus valores de data e hora no banco de dados (ou em arquivos serializados ou comunicações XML/JSON) em UTC. Escreva a maior parte de sua lógica de negócios em UTC, exceto quando o fuso horário local for importante, como definir "o início de um novo dia".
Ao apresentar para o usuário, use o formato ISO 8601 ou localize para seu próprio fuso horário (ou o fuso horário esperado). Isso segue a ideia básica de internacionalização/localização. Para valores de texto, você usa determinadas strings de chave em seu código. Na apresentação na interface do usuário, você mapeia essas strings internas para valores de texto localizados (traduzidos) para a interface do usuário. Alguns com data e hora:UTC internamente, fuso horário local na interface do usuário.
Uma advertência:você pode querer também armazenar uma data e hora local para fins de histórico. As regras de fuso horário mudam com frequência e caprichosamente por causa de políticos e burocratas. O banco de dados de fuso horário do seu software pode estar desatualizado. Portanto, você pode armazenar o que você ou o usuário acredita ser uma determinada data e hora então . Mas não confie nisso; determinar e armazenar o valor UTC.
Dica:Aprenda a pensar e ler em 24 horas. Sua vida como programador/depurador/administrador de sistema se tornará muito mais fácil e menos propensa a erros.
Joda-Time ou java.time
As classes java.util.Date e .Calendar empacotadas com Java são notoriamente problemáticas. Evite-os.
Em vez disso, use Joda-Time ou o novo pacote java.time embutido no Java 8 (inspirado no Joda-Time, definido pelo JSR 310).
Ambas as bibliotecas usam os formatos ISO 8601 como padrão, tanto para análise quanto para geração de strings.
ISO 8601
ISO 8601 é um padrão sensato que define como apresentar valores de data e hora, fusos horários e deslocamentos, durações e períodos em formatos textuais específicos e não ambíguos. Estude aquela página bem escrita da Wikipedia.
Observe em particular o que o padrão chama de Durações . Um intervalo de tempo é definido neste formato:
PnYnMnDTnHnMnS onde P significa "Período", o T separa a parte da data da parte da hora, e as outras partes opcionais são dígitos + letra. Um compromisso de meia hora seria PT30M . Isso pode ser útil para você, como para o campo "period_" visto em meu ERD
abaixo de. No Joda-Time, a classe Period representa um intervalo de tempo rastreando seus meses, dias, horas, etc., e sabe como analisar e gerar strings nesse formato. Semi-aberto
Você pode optar por armazenar compromissos de duas maneiras. Uma maneira é uma data e hora de início e uma duração (90 minutos, 20 minutos, etc.). Outra maneira é gravar uma data e hora de início e término. Nesse caso, a abordagem usual e geralmente melhor é chamada de "Half-Open". Isso significa que o início é inclusivo enquanto o final é exclusivo .
Por exemplo, um compromisso de uma hora na hora seria executado das 11h às 12h, o que significa "começando às 11h e indo até, mas não incluindo, o primeiro momento da próxima hora (meio-dia)". A próxima consulta será das 12:00 às 13:00.
Pesquise no StackOverflow por "Half-open" para encontrar mais discussões, exemplos e diagramas.
Muitos para muitos
A relação entre Paciente e Doutor é o que chamamos de Many-To-Many . Um médico atende muitos pacientes, e um paciente pode ver mais de um dos médicos. Certifique-se de conhecer as tabelas Muitos para Muitos no design de banco de dados relacional. A solução é sempre adicionar uma terceira tabela, às vezes chamada de tabela "ponte" que serve como uma tabela filha para ambas as outras tabelas pai. No seu caso, o Compromisso mesa é a mesa de ponte.
Você precisará saber como realizar junções em um relacionamento muitos-para-muitos.
SQL direto
Se você é novo em programação ou novo em banco de dados relacional, sugiro evitar o Hibernate. Você realmente deve ter uma noção do que está acontecendo. O Hibernate tem alguns usos apropriados. Mas se você acha que o Hibernate fará magicamente desaparecer os problemas do banco de dados, ficará desapontado.
Atributos
Os atributos são com você. Eles dependem do problema de negócios (ou dever de casa?) que você está tentando resolver. Você tem o básico certo.
O agendamento de compromissos é um problema de negócios muito difícil para o qual escrever software. Por exemplo, você está simplesmente registrando os compromissos que estão sendo feitos? Ou você está rastreando a disponibilidade dos médicos, criando intervalos de tempo predefinidos e, em caso afirmativo, como lida com exceções e alterações no calendário de cada médico? Você precisa escrever requisitos e casos de uso muito específicos. Muito fácil para as expectativas dos usuários excederem seus supostos requisitos.
Aqui está uma visão simplista.
