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
LostSpirit
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?
Lucas_Camara
Blz. Isso deixa mais claro. Nesse caso, basta vc puxar a chave da tabela services_types para a tabela service como FK.
LostSpirit
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
Lucas_Camara1 like
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)
LostSpirit
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?
Solucao aceita
Lucas_Camara1 like
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 =)
LostSpirit1 like
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.
Lucas_Camara1 like
Perfeito. Tu sacou.
Isso mesmo!
LostSpirit
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?
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.
LostSpirit
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.
Lucas_Camara1 like
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.
entendi mas eu teria que relacionar o tipo do serviço nessa tabela também não? pq ele que vai interferir no valor
Lucas_Camara1 like
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).
LostSpirit
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?