Eu alteraria o nome da tabela elo para liga_divisao, e removeria dela a coluna id ficando assim somente as colunas liga_id e divisao_id onde as mesmas seriam PK/FK, desta forma ficaria restrito as relações de cada liga com divisão não permitindo valores repetidos!
sim exemplo cs go e lol
tem o global que não tem divisão
e no lol / mestre e challenger grão mestre etc…
no caso eu poderia botar divisão 1 ou seja divisão única?
eu poderia considerar no caso, como tendo apenas uma divisão ( divisão 1) algo do tipo?
Nesse caso defina os campos somente como FK permitindo que aceitem valores nulos, aí para cada tipo de jogo que você desejar controlar valide as regras de cada um via aplicação e veja para quais deles é obrigatório informar uma divisão e valide isso antes da persistência.
eu fiz esse relacionamento, onde eu queria definir os valores de uma forma dinâmica de cada " Liga ( tier) "
e cada liga poderia ter mais de um valores ( isso seria definido pelo tipo de service_mode, e ranked_mode)
exemplo:
o preço do
elo job single + ranked solo/duo no elo bronze é um
duo job + ranked solo/duo no elo bronze é outro.
Mas eu tenho um pequeno requisito que não estou conseguindo imaginar como solucionar isso, ou seja cada Liga(Tier ) : bronze , prata etc etc tem um valor uniforme ou seja do bronze 4 ao bronze 1 o valor é 10 reais por cada divisão ou seja bronze 4 para o bronze 3 10 reais, bronze 3 para o bronze 2 10 reais,
mas na liga DIAMANTE os valores já não são uniformes são diferentes de divisão para divisão.
Se os valores dependem de uma liga e uma divisão para serem compostos, você pode relacionar tiers_division com elo_prices, se depende só de liga relaciona com tiers e se depende só de divisão relaciona com division.
eu não sei se está normalizado ou correto, eu deixei tier_id como fk na tabela tier_divisions, e fiz uma relacionamento com a tabela de preços 1:n por que um tier pode ter mais de um preço.
Você ver algum error ou eu posso melhorar em algo?
Nessa abordagem seria interessante tu manter as FK’s na tabela tier_divisions e criar uma PK nela para que possa criar o relacionamento com a tabela elo_price.
eu creio que tenha terminado a base, mas não sei se o meu relacionamento de usuário e comprar serviços.
minha tabela service é basicamente serviços adicionais que vão acrescentar o valor na compra com a %, e uma compra pode ter mais de um serviço.
e na minha tabela purchase eu tenho o id do usuário que comprou, o modo do serviço, ranked_mode
Eu estou com dúvida onde eu deveria por um campo para armazenar o valor final da compra, ou seja o elo_price com a adição das % dos services adicionais da compra.
eu poderia melhorar em algo com relação a esse relacionamento de purchase?
E sobre a tabela elo_price eu não precisaria relacionar ela com a compras já que não seria o preço final, eu apenas utilizaria ela para pegar o valor total de um elo para o outro, e adicionaria a % do meu services que geraria o valor do campo preço.
sim, no caso eu precisaria armazenar o valor total da compra, no caso o valor base seria a soma total do elo inicial até o elo final ( onde eu armazeno os valores no elo_price)
e também com a aplicação das % que eu tenho na minha tabela service por isso eu criei esse relacionamento service_purchase, por que eu posso ter mais de um serviço em uma compra, exemplo serviço 1: adicionar 5% ao valor , serviço 2 adicionar 50% ao valor.
e então o preço final ficaria armazenado em purchase?
A sua própria lógica é auto explicativa, veja bem:
Aplica-se valor para cada serviço da compra? se sim, armazena-se o valor de cada serviço da compra em service_purchase. (valor pelo qual o serviço foi vendido para aquela compra)
Precisa armazenar o valor total da compra? se sim, armazena-se na compra, neste ponto não entra no mérito do que foi adicionado a compra, o que me interessa nesse ponto é o valor total, por isso armazena-se em purchase.