Marnix.hoh's questions

Digamos que temos as seguintes tabelas:

• user
• team
• meeting

Tanto a teamquanto a meetingpodem ter múltiplos users(relação de 1 para muitos).

Qual é a melhor maneira de modelar essa estrutura de banco de dados?

Opção 1:

1 tabela de junção para os relacionamentos team-usere meeting-user:

colunas: user_id, team_id, meeting_id
linhas de exemplo: 1, 3, null 1, null, 4

Opção 2:

2 tabelas de junção, uma para o relacionamento team-usere outra para o meeting-userrelacionamento

colunas tabela 1: user_id, team_id
linha de exemplo:1, 3

colunas tabela 2: user_id, meeting_id
linhas de exemplo:1, 4

Atualmente, estou armazenando transações financeiras na tabela a seguir (abreviada para resumir):

id INT
start DATETIME
end DATETIME
rate INT
usage INT
usage_fee INT
amount INT
commission_pct INT
payout INT
currency VARCHAR(5)

O valor total cobrado de um cliente é calculado da seguinte forma: amount = (end - start) * rate + usage * usage_fee

A plataforma cobra uma taxa/comissão de: commission = amount * (commission_pct / 100)

O pagamento que o provedor de serviços recebe é: payout = amount - commission

Agora, na tabela acima, armazenar o pagamento é tecnicamente redundante, pois pode ser calculado conforme mostrado acima. Minha pergunta é: qual é a maneira/convenção comum de armazenar esses tipos de transações financeiras em relação à redundância de dados?

Por exemplo, estou pensando em armazenar também o resultado de (end - start) * ratee usage * usage_feeseparadamente nesta tabela, além de sua soma (quantidade).

Os prós que vejo de fazer isso são:

• sem erros (de arredondamento) ao enviar os respectivos valores para a "API do provedor de pagamento", ou seja, o que o usuário acaba pagando é exatamente o mesmo que está armazenado no banco de dados ao invés de enviar valores computados para a referida API
• consultas e análises fáceis

Esses prós são válidos ou você me recomendaria normalizar completamente a tabela e calcular os valores sempre que necessário?

Eu sei que normalizar a tabela é a resposta correta de acordo com "princípios de design de banco de dados", mas como estou lidando com dados financeiros, não tenho certeza se estou 100% confortável usando valores calculados.

A taxa de comissão não é específica por transação, mas o commission_pct cobrado provavelmente mudará no futuro e, portanto, é armazenado junto com cada transação. É claro que não seria necessário armazenar a porcentagem da comissão se o "valor da comissão" real for armazenado.

A comissão_pct e a taxa usada naquele momento são armazenadas na tabela, e é por isso que alterá-las no futuro para transações subsequentes não é um problema e as transações existentes nunca serão editadas. Além disso, há apenas um aplicativo controlado que tem acesso ao banco de dados. Se a fórmula mudar no futuro, não ter os resultados computados e armazenados seria um problema. Estou inclinado para o aplicativo que calcula esses valores e armazena os valores "brutos" e calculados de uma só vez.