Tenho esse cenário onde um funcionário pode ter vários endereços então criamos uma tabela relacional EmployeeAddress, agora na equipe sugeriram adicionar um AddressId na tabela Employee que vai ser o principal e depois no EmployeeAddress tendo o restante endereços, é claro, aquele que você atribui como principal deve ser um dos endereços que vêm na tabela EmployeeAddress, essa é uma boa abordagem ou é melhor sempre ir para EmployeeAddress e colocar uma coluna lá IsPrimary para encontrar o principal?
Minha preferência para isso seria adicionar um sinalizador à tabela EmployeeAddress indicando que é o endereço principal.
Existem advertências, no entanto. Algo, seja o aplicativo ou um gatilho, deve garantir que apenas um endereço possa ser o principal por vez. Isso pode ser feito observando todos os endereços de um funcionário e certificando-se de que apenas um esteja marcado, ou pode ser que o endereço principal esteja de fato na tabela Funcionário e simplesmente colocando-o lá.
... O que é um longo caminho para dizer que posso ver os argumentos nos dois sentidos. Acho que os formulários normais diriam para colocar o sinalizador IsPrimary na tabela EmployeeAddress, pois esse é o local mais apropriado para isso.
É difícil dizer qual caminho é melhor, mas você pode considerar cenários de uso, dificuldade de programação, capacidade de manutenção, tamanho dos dados, carga do banco de dados e muito mais. Aqui está uma comparação que fiz.
AddressType.Name, só precisaJOINEmployeeAddresseAddress, caso contrário,JOINtodas as 4 tabelasJOINtodas as 4 mesasJOINtodas as 4 mesasJOINEmployeeAddress,Address,AddressTypeEmployee,EmployeeAddress,Addressem uma transaçãoEmployeeAddress,Addressem uma transaçãoEmployeeAddress,AddressEmployeeAddress,AddressEmployeeEmployeeAddressNOT NULLrestriçãoAddressIdinEmployeetêm valorNULLemIsPrimayEmployeeAddressEmployeecontém muitas colunas para armazenar informações dos funcionários. Isso significa que pode haver diferentes casos de uso para atualizarEmployeeao mesmo tempo, bloqueios simultâneos têm mais chances. Tabela maior significa tempo de transação mais longo. Isso pode causar efeitos mais negativos neste caso (endereço principal) e em outros casos de uso.AddresseEmployeeAddressé muito simples, as chances de operações simultâneas no mesmo endereço de funcionário são muito menores e as tabelas são muito menores, o commit da transação é mais rápido.Meu pensamento é que, se o
Employeenão for projetado para ter muita capacidade, seria mais conveniente usarAddressIDinEmployee, caso contrário, usarIsPrimaryinEmployeeAddressserá mais escalável.Espero que isso seja útil para sua discussão.