Olá eu tenho o seguinte relacionamento:
bom, mas eu fiquei com a seguinte dúvida:
um serviço só pode ter apenas um tipo, mas os types podem fazer parte de mais de um serviço?
seria um relacionamento 1:n ou eu estou viajando?
Alguém poderia me ajudar, qual seria a melhor relação entre types e services?
Ou eu estou tendo a logica errada? seria um relacionamento 1:1?
Parece que é 1:n mesmo (1 serviço tem 1 ou mais tipos). Agora se um mesmo tipo puder ser de mais de um serviço, já seria um n:n (com isso, precisaria ter uma tabela para relacionar os tipos com os serviços):
tipo
----
ID
----
A
B
C
D
servico
----
ID
----
1
2
3
4
servico_tipo
--------+-----------
id_tipo | id_servico
--------+-----------
A | 1
A | 2
B | 1
A | 3
no caso um serviço só pode ter um único tipo, mas mesmo assim creio que ainda seja um relacionamento 1:n, fiquei com dúvida de como relacionar isso kkk você pdoeria me ajudar?
Blz. Isso deixa mais claro. Nesse caso, basta vc puxar a chave da tabela services_types para a tabela service como FK.
ahh então seria um relacionamento 1:1?
tipo eu tava me fazendo essa seguinte pergunta:
um serviço pode ter apenas um único tipo, e os tipos podem ser de vários serviços, acho que essa analogia está errada, não é?
viajei hehe kk
Não necessariamente
O tipo A associado ao serviço 1 também pode ser associado ao serviço 2.
Acho que uma dúvida sua é quando tornar uma relação 1:1. Ao meu ver, isso é mais um comportamento da modelagem do que na forma de modelar.
Vc quem define isso. Se vc quiser quer um Tipo chamado Tipo A seja relacionado aos Serviço 1 e Serviço 2, vc pode fazer isso tendo dois Tipos com IDs diferentes com o mesmo nome. E isso implicaria em uma relação 1:1 (pois são tipos “diferentes” - cada um com seu id - para serviços diferentes)
entendo então acho que seria a opção mais viável colocar a id do tipo como fk no service, seria a opção mais correte, no caso?
Como o serviço pode ter apenas um tipo, sim.
Vou aprofundar um pouco:
Em grandes sistemas, geralmente há um requisito que é manter o histórico de ações no banco. Supondo que seja necessário ter o histórico de ações referentes à serviços de determinados tipo, e que esse tipo seja alterado em algum momento, e que seja necessário manter que “as ações envolvendo o serviço tal tenha sido quando ele ainda era do tipo tal”, ai sim seja necessário uma modelagem para atender esse tipo de cenário.
Entendeu? Acho que ficou meio macarronado o cenário que tentei explicar kkk =)
entendi, realmente kkk, ai creio que já entraria relacionamento n:n, mas ficou muito boa sua explicação, obrigado man, então eu não estava tão errado, poderia ser considerado 1:n.
Perfeito. Tu sacou.
Isso mesmo!
man você poderia me ajudar só com mais uma questão?
tipo eu tenho o preço no serviço, mas eu queria botar os preços no mode, mas para cada tipo de serviço o mode tem um valor diferente, então eu fico com dúvida como eu faria isso.
por que cada mode vai ter um valor, mas esse valor pode alterar de acordo com o tipo do serviço, ai eu fiquei bugado como representar isso no banco ou isso seria mais na logica da programação?
Talvez seria o caso da modelagem ser assim:
Servico_Mode
id -> nesse caso, usar uma chave burra seria bom para evitar complexidade no código, com isso todos os registros relacionados para um serviço e um mode, serão referenciados por esse ID (com isso, mantendo histórico)
idServico
idMode
preco
situacao --> vc pode usar essa coluna para indicar se um serviço com determinado mode está ativado ou não
E, se for o caso, vc ainda pode ter uma unique constraint para garantir que não tenha mais de um registro ativo para o mesmo serviço e mode.
mas tipo nesse modo eu definiria o preço na tabela servico, eu tava pensando em definir o preço em uma tabela separada
exemplo:
cada mode tem um valor, mas dependendo do tipo o valor pode ser menor ou maior…
tou um pouco confuso com isso, mas básicamente é assim o mode tem um valor, mas ele é diferente dependendo do serviço, mas eu queria deixar setado os valores como padrões em uma tabela ex
mode_serviceA_values
mode_serviceB_values
mas creio eu que esteja errado.
Desse tipo que passei, já eh uma tabela nova (Service_Mode). Nela teria a FK do Service e do Mode. Não seria mais necessário ter o id do mode na sua tabela de service.
Ex:
---+-----------+---------+-------+----------+
id | idService | id_mode | preco | situacao |
---+-----------+---------+-------+----------+
1 | 1 | 1 | 1.00 | INATIVO |
2 | 1 | 2 | 2.00 | ATIVO |
3 | 2 | 1 | 3.00 | INATIVO |
4 | 2 | 2 | 4.00 | ATIVO |
---+-----------+---------+-------+----------+
entendi mas eu teria que relacionar o tipo do serviço nessa tabela também não? pq ele que vai interferir no valor
Isso é uma informação importante. Nesse caso, então sim. Vc deve trazer o tipo do service para essa tabela tb (mas mantenha o tipo do serviço na tabela de serviço).
man você poderia me ajudar só mais uma vez? kkkk
tou quebrando cabeça
básicamente tou tentando fazer um sistema de elo, tipo lol, cs e etc.
onde se em liga e divisões.
liga tipo: bronze etc…
divisões: 1 até 4
e então eu pensei nisso como um relacionamento n:n que formaria o elo?
tipo isso:
mas tou com dúvida se está correto ou poderia melhorar isso.
um único elo tem 4 divisões.
bronze 1 2 3 4
prata 1 2 3 4
eu entendo que básicamente o elo: seria bronze / divisão 4
mas eu não sei se está correto a relação divisão/liga.
Já que é definido que as ligas tem 4 divisões.
