Eu tenho uma tabela de banco de dados contendo uma lista de sistemas relevantes para a ferramenta que estou construindo, principalmente aplicativos internos ou sistemas de terceiros dos quais recebemos dados. Esta tabela é adicionada a infrequentemente, aproximadamente a cada 2 meses.
Um desses sistemas é o próprio Windows, que é onde armazenamos as LANs dos nossos usuários, e agora preciso referenciar explicitamente o ID relacionado ao Windows para consultar o nome do usuário, a equipe etc. Eu sei que seria uma prática ruim incorporar o próprio ID no código, então minha pergunta é qual seria a melhor maneira de evitar isso? Estou assumindo que minhas opções são:
Eu aprecio isso pode parecer uma questão trivial, mas eu vou ter muitas situações como esta durante o curso desta compilação, e apesar de estarmos no controle completo do banco de dados, eu gostaria de estar em conformidade com as melhores práticas, tanto quanto possível.
Muito obrigado!
Resposta curta: eu manteria meus dados no banco de dados. A última opção é boa.
retrieve the ID from the database based on system name
Para lidar normalmente com os IDs aos quais você está se referindo, você pode usar Dicionários para carregar todos os IDs de referência da tabela do banco de dados ( s) dentro de sua aplicação. Dependendo da frequência com que esses IDs podem mudar, você também pode armazenar em cache este dicionário para um desempenho muito melhor.
Retrieve the ID from the database based on system name
Todas as suas outras opções envolvem a duplicação dos dados do banco de dados em seu código. O design do banco de dados e do programa geralmente é um processo de redução da duplicação de dados, não aumentando-o.
Se você estivesse começando do zero, e não esperasse um novo sistema com muita frequência e houvesse apenas alguns sistemas, talvez você começasse com um enum. Quando você se cansava de recompilar e relançar o código toda vez que você suportava um novo sistema, então você criaria uma tabela de banco de dados. Mas como você já tem uma tabela de banco de dados, não consigo pensar em uma razão para não usá-la.
I now need to explicitly reference the ID relating to Windows to query for user name, team etc.
Simples:
select u.user_name, u.team, u.other_field
from user u
join system s on u.system_id = s.id
where s.name = 'Windows';
Ou se o mesmo usuário puder estar em vários sistemas:
select u.user_name, u.team, u.other_field
from user u
join user_system_xref usx on usx.user_id = u.id
join system s on usx.system_id = s.id
where s.name = 'Windows';
Hmm ... Eu vejo a tag "Orientada a objeto" em sua postagem. Eu acho que vou apenas um pouco mais e dizer que se você estiver usando o Hibernate, você pode fazer algo semelhante com uma consulta de critérios:
Crit<System> crit = Crit.create(System.class);
crit.add(Restrictions.eq("name", "Windows"));
System currSystem = crit.uniqueResult();
for (user : currSystem.getUsers()) {
System.out.println(user.getName());
System.out.println(user.getTeam().getName());
}
Os dados que são alterados devem ser mantidos em um arquivo de configuração ou no banco de dados. Os dados que precisam ser usados em consultas que representam dados corporativos devem estar no banco de dados. Eu escolheria integridade sobre desempenho especialmente para dados de tamanho pequeno. Eu iria com opção 4. Lembre-se que as alterações no código requer gerenciamento de versão. Se isso se tornar prática frequente, você poderá gastar tempo desnecessário no gerenciamento de versões.
Idealmente, seria melhor consultar o banco de dados e armazenar os dados retornados para uso futuro. Criar enums para tabelas específicas onde você precisa dos IDs duplica os dados que você pode obter de outra forma que deve ser evitada. Dito isto, porém, em muitos casos, faz mais sentido na prática criar enums com esses dados e atualizá-los à medida que você atualiza as informações nessas tabelas, porque o esforço envolvido em fazê-lo da maneira "correta" só compensa se as tabelas mudar um pouco com freqüência. O esforço envolvido para atualizar um enum uma vez por ano adicionando uma entrada ou duas não é significativo.
Não crie nada tão global, crie uma classe de constantes e a exponha somente onde for necessário. Também seria melhor ir em frente e criar a tabela inteira como um enum agora, esse método pode ficar realmente feio se o enum ficar fora de sincronia com o banco de dados.