Devo colocar o atributo em cada tabela mesmo que estejam vinculados para aumentar o desempenho?

Seria uma má prática colocar uma data em cada tabela mesmo que sejam iguais?

Sim. Isso coloca você em risco de manter a integridade dos dados, por exemplo, quando os dados errados foram inseridos e precisam ser atualizados. Agora você deve certificar-se de atualizar todas as 3 tabelas com o valor correto, de forma transacionalmente consistente. Basicamente, você sempre precisaria usar uma transação explícita agrupada em torno das alterações DML ( INSERTs, UPDATEs e DELETEs) de todas as 3 tabelas para garantir a consistência adequada dos dados entre elas, caso ocorresse um erro ou caso o banco de dados ou o aplicativo falhasse.

Falando nisso, atualizando o mesmo ponto de dados 3x mais frequentemente agora, e sendo forçado a agrupar as alterações de todas as 3 tabelas na mesma transação, você acaba impactando negativamente o desempenho devido ao aumento da quantidade de trabalho, e o aumento da quantidade de tempo as tabelas serão bloqueadas durante as gravações, o que bloqueará outros escritores (e dependendo do seu nível de isolamento, outros leitores) para essas tabelas, que poderiam ter acontecido anteriormente simultaneamente.

Colocar a data apenas em "Rep Log" não prejudicaria o desempenho?

Não. Isso é chamado de pensamento de otimização prematura . Com tabelas arquitetadas e indexadas adequadamente, a JOINobtenção do datecampo da Workout Logtabela deve levar alguns milissegundos ou menos, independentemente do tamanho das tabelas.

Existem alguns casos de uso de exceção em que uma tabela desnormalizada com pontos de dados pré-calculados pode melhorar o desempenho de relatórios em grande escala. Mas isso ocorre normalmente apenas quando você planeja executar agregações que envolvem a maioria ou todas as linhas de grandes tabelas transacionais. Os casos de uso de seu aplicativo não se enquadram nessa categoria.

Siga padrões típicos de design de normalização e arquitetura de índice e não se preocupe com a otimização prematura antes de ter um problema real de desempenho à sua frente. Como a solução para o referido problema de desempenho será um fato muito específico para os dados existentes naquele momento. Não é possível otimizar para tal problema antes que ele exista.