Olá, Radio SQL está no ar novamente! Amasse os gânglios, espalhe pseudópodes (ou vice-versa?) E sintonize nossa onda gravitacional!
Na última vez, eu fui praticamente excluída por analisar (
https://habr.com/en/post/359064/ ) o problema do Olympiad SQL, supostamente não estava perto o suficiente da vida. Como se as tags "programação anormal" e "Olimpíadas" não falassem por si mesmas. Mas, obviamente, ninguém lê as tags! No entanto, continuarei o tópico de análise de tarefas na maravilhosa linguagem de programação SQL. Porque as patas (coceira).
Hoje nos deparamos com uma tarefa exclusivamente com risco de vida e até prática. Encontrei-o, tentando calcular o desempenho do SLA em solicitações de usuários apaixonados. A essência do problema inicial é a seguinte: era necessário calcular a duração do trabalho para cada aplicativo e comparar com o que prometemos. Tudo ficaria bem, mas o tempo nas obrigações foi declarado funcionando e, a partir das alterações de status nos aplicativos, eu consegui apenas o calendário. E aqui está um pensamento! Aqui está ela, tarefa! Não é muito complicado, mas também não é trivial. Apenas para esticar as partes centrais do seu sistema nervoso autônomo, tornando-os mais simpáticos!
Então, eu declaro a condição.
Existem vários intervalos de tempo especificados pela data e hora do início e do fim (um exemplo na sintaxe do PostgreSQL):
with periods(id, start_time, stop_time) as ( values(1, '2019-03-29 07:00:00'::timestamp, '2019-04-08 14:00:00'::timestamp), (2, '2019-04-10 07:00:00'::timestamp, '2019-04-10 20:00:00'::timestamp), (3, '2019-04-11 12:00:00'::timestamp, '2019-04-12 16:07:12'::timestamp), (4, '2018-12-28 12:00:00'::timestamp, '2019-01-16 16:00:00'::timestamp) )
É necessário em uma consulta SQL (c) calcular a duração de cada intervalo em horário comercial. Acreditamos que trabalhamos durante a semana de segunda a sexta-feira, o horário de trabalho é sempre das 10:00 às 19:00. Além disso, de acordo com o calendário de produção da Federação Russa, existem vários feriados oficiais que não são dias úteis e alguns dias de folga, pelo contrário, são dias úteis devido ao adiamento desses mesmos feriados. Não é necessário o encurtamento dos dias pré-feriado, nós os consideramos completos. Como os feriados variam de ano para ano, ou seja, são definidos por listagem explícita, nos limitaremos a datas apenas de 2018 e 2019. Estou certo de que, se necessário, a solução pode ser facilmente complementada.
É necessário adicionar uma coluna com a duração do horário de trabalho aos períodos iniciais dos
períodos . Aqui está o resultado:
id | start_time | stop_time | work_hrs
Não verificamos os dados iniciais quanto à exatidão; sempre consideramos
start_time <= stop_time .
As construções especiais de dialeto SQL do PostgreSQL podem ser usadas, mas não abusadas. Para total correção das condições, acrescento que a consulta deve ser executada no PostgreSQL versão 10 ou posterior.
Em um mês, haverá uma análise da tarefa. Não tomo nenhuma decisão para que haja um incentivo para resolver por conta própria. Pedimos gentilmente - coloque o código nos comentários abaixo dos spoilers!
Por último mas não menos importante . Se eu já consegui publicar este artigo no blog corporativo do Postgres Professional, usaremos alguns brindes corporativos: para a solução mais interessante para esse problema, faremos uma viagem gratuita ao
PGConf.Russia 2020 . Os critérios de interesse serão pessoalmente meus, mais os dos colegas com quem considero necessário consultar. Boa sorte
ATUALIZAÇÃO! Algo que vejo que o horário de trabalho é percebido por algum motivo exclusivamente sem minutos de trabalho. Não esqueça os minutos! Ajustei os intervalos iniciais e a resposta esperada para enfatizar a disponibilidade de minutos.
Resumo da
ATUALIZAÇÃO2 :
https://habr.com/en/company/postgrespro/blog/457722/ .