Gerenciando funções e status em um sistema

Ideia básica

Modelo Simples

1. 
   Não mantemos nenhum dado histórico (ou futuro).
   
   Quando alteramos o status ou função, simplesmente atualizamos status_id e role_id na user_account tabela. Isso funcionará bem por enquanto, então, quando fizermos uma alteração, ela refletirá no sistema. Tudo bem se não precisarmos saber como os status e as funções mudaram historicamente. Além disso, há um problema em que não podemos adicionar futuro função ou status sem adicionar tabelas extras a este modelo. Uma situação em que provavelmente gostaríamos de ter essa opção é quando sabemos que alguém estará de férias a partir da próxima segunda-feira. Outro exemplo é quando temos um novo funcionário; talvez queiramos inserir seu status e função agora e que se torne válido em algum momento no futuro.
   
   Há também uma complicação caso tenhamos eventos agendados que usam funções e status. Eventos que preparam dados para o próximo dia útil geralmente são executados enquanto a maioria dos usuários não usa o sistema (por exemplo, durante a noite). Portanto, se alguém não trabalhar amanhã, teremos que esperar até o final do dia atual e alterar suas funções e status conforme apropriado. Por exemplo, se tivermos funcionários que trabalham atualmente e têm a função de “funcionário de call center”, eles receberão uma lista de clientes para os quais devem ligar. Se alguém por engano tiver esse status e função, ele também receberá seus clientes e teremos que gastar tempo corrigindo isso.
   
2. 
   O usuário pode ter apenas uma função por vez.
   
   Geralmente, os usuários devem poder ter mais de uma função no sistema. Talvez no momento em que você está projetando o banco de dados não haja necessidade de algo assim. Tenha em mente que podem ocorrer mudanças no fluxo de trabalho/processo. Por exemplo, em algum momento o cliente pode decidir mesclar duas funções em uma. Uma solução possível é criar uma nova função e atribuir a ela todas as funcionalidades das funções anteriores. A outra solução (se os usuários puderem ter mais de uma função) seria que o cliente simplesmente atribua ambas as funções aos usuários que precisam delas. Claro que essa segunda solução é mais prática e dá ao cliente a capacidade de ajustar o sistema às suas necessidades mais rapidamente (o que não é suportado por este modelo).
   

select user_account.id, user_account.role_id
from user_account
left join status on user_account.status_id = status.id
where status.is_user_working = True
and user_account.user_name = @user_name
and user_account.password_hash_algorithm = @password;

@user_name e @password são variáveis ​​de um formulário de entrada enquanto a consulta retorna o id do usuário e o role_id que ele possui. Nos casos em que nome_usuário ou senha não são válidos, o par nome_usuário e senha não existe ou o usuário tem um status atribuído que não está ativo, a consulta não retornará nenhum resultado. Dessa forma, podemos proibir o login.

Este modelo pode ser usado nos casos em que:

• temos certeza de que não haverá mudanças no processo que exijam que os usuários tenham mais de uma função
• não precisamos rastrear alterações de funções/status no histórico
• não esperamos ter muita administração de função/status.

Componente de tempo adicionado

select *
from user_has_status
where user_has_status.user_account_id = @user_account_id
and 
(
# test if @start_time included in interval of some previous status
(user_has_status.status_start_time <= @start_time and ifnull(user_has_status.status_end_time, "2200-01-01") >= @start_time)
or
# test if @end_time included in interval of some previous status  
(user_has_status.status_start_time <= @end_time and ifnull(user_has_status.status_end_time, "2200-01-01") >= ifnull(@end_time, "2199-12-31"))  
or  
# if @end_time is null we cannot have any statuses after @start_time
(@end_time is null and user_has_status.status_start_time >= @start_time)  
or
# new status "includes" old satus (@start_time <= user_has_status.status_start_time <= @end_time)
(user_has_status.status_start_time >= @start_time and user_has_status.status_start_time <= ifnull(@end_time, "2199-12-31"))  
)

@start_time e @end_time são variáveis ​​que contêm a hora de início e a hora de término de um status que queremos inserir e @user_account_id é o ID do usuário para o qual o inserimos. @end_time pode ser nulo e devemos tratá-lo na consulta. Para este propósito, os valores nulos são testados com o ifnull() função. Se o valor for nulo, um valor de data alto será atribuído (alto o suficiente para que, quando alguém perceber um erro na consulta, já estejamos fora :). A consulta verifica todas as combinações de hora de início e hora de término para um novo status em comparação com a hora de início e a hora de término dos status existentes. Se a consulta retornar algum registro, temos sobreposição com status existentes e devemos proibir a inserção do novo status. Também seria bom gerar um erro personalizado.

Se quisermos verificar a lista de funções e status atuais (direitos do usuário), simplesmente testamos usando a hora de início e a hora de término.

select user_account.id, user_has_role.id
from user_account
left join user_has_role on user_has_role.user_account_id = user_account.id
left join user_has_status on user_account.id = user_has_status.user_account_id
left join status on user_has_status.status_id = status.id
where user_account.user_name = @user_name
and user_account.password_hash_algorithm = @password
and user_has_role.role_start_time <= @time and ifnull(user_has_role.role_end_time,"2200-01-01") >= @time
and user_has_status.status_start_time <= @time and ifnull(user_has_status.status_end_time,"2200-01-01") >= @time
and status.is_user_working = True

@user_name e @password são variáveis ​​do formulário de entrada enquanto @time pode ser definido como Agora(). Quando um usuário tenta fazer login, queremos verificar seus direitos naquele momento. O resultado é uma lista de todas as funções que um usuário possui no sistema caso o nome_do_usuário e a senha correspondam e o usuário tenha atualmente um status ativo. Se o usuário tiver um status ativo, mas nenhuma função atribuída, a consulta não retornará nada.

Essa consulta é mais simples que a da seção 3 e esse modelo nos permite ter um histórico de status e papéis. Além disso, podemos gerenciar status e funções para o futuro e tudo funcionará bem.

Modelo final

select user_account.id, user_has_role.id
from user_account
left join user_has_role on user_has_role.user_account_id = user_account.id
left join status on user_account.current_status_id = status.id
where user_account.user_name = @user_name
and user_account.password_hash_algorithm = @password
and user_has_role.role_start_time <= @time and ifnull(user_has_role.role_end_time,"2200-01-01") >= @time
and status.is_user_working = True

• em cada inserção/atualização/exclusão em user_has_status tabela
• todos os dias em um evento agendado, devemos verificar se o status de alguém mudou (status ativo atual expirou ou/e algum status futuro se tornou ativo) e atualizá-lo adequadamente