Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Boa Tarde!
Seguem 3 tabelas para exemplificar meu problema:
create table clintes(id int(4) not null, nome varchar(200) not null, primary key (id));
create table fornecedores(id int(4) not null, nome varchar(200) not null, primary key (id));
create table telefones(id_telefone int(3) not null, telefone int(12) not null, id_origem int(4) not null, primary key (id_telefone));
Onde id_origem seria o id ou do cliente ou do fornecedor. A minha dúvida é a seguinte: existe maneira para que eu possa relacionar a tabela telefones com as duas tabelas clientes e fornecedores para cadastrar todos os telefones em uma tabela só ou devo criar duas tabelas de telefones, uma de telefones_clientes e outra de telefones_fornecedores e cadastrar cada qual na sua?
Como você identificaria o telefone do cliente 1 se já existir um telefone para o fornecedor 1?
Eu manteria todas as tabelas que exemplificou, mas com um detalhe que apontarei mais adiante.
Criaria uma tabela nomeada pessoas ou um nome mais propício, para cadastrar todos os clientes juntos com os fornecedores, pois todos são pessoas, e somente existiria um único registro para cada um deles.
Agora, para as tabelas clientes e fornecedores, eu mudaria o id para ser um FOREIGN KEY da tabela pessoas, se a pessoa for cliente, cadastro ela também na tabela de clientes, caso ela seja fornecedor, cadastro ela também na tabela de clientes. Isso permite que exista uma pessoa que seja fornecedor e cliente, cito como exemplo um fornecedor de supermercado, que faz suas compras no mesmo mercado que fornece seus produtos.
Então na tabela telefones eu poderia simplesmente utilizar o id da tabela pessoas. Entendeu meu raciocínio?
Existe algum motivo forte para separar esta tabela de telefones ?
Em geral um simples atributo (campo) resolve na minha opinião.
Seu modelo não é errado tem a vantagem de permitir n telefones de um cliente/fornrcedor
Acho porém que falta um atributo para indicar o tipo ( celular, casa, trabalho, recado etc) do telefone.
Eu criaria o campo de telefones na tabela clientes e na tabela fornecedores. Uma coisa é cliente, outra coisa é fornecedor. Se quisesse reuinir esses dados em uma lista depois, faria SQL diferentes ou resolveria com uma VIEW.
Agora, se você quer manter estas tres tabelas, além do id_origem vc precisa do id_tipo, que vai dizer se é cliente ou fornecedor.
Mas lembre que, se vc pensar um pouco, vai querer manter o endereco fora tb ? E o email ? Nisso surge a necessidade de você criar uma tabela chamada contatos, com os mesmos id_origem e id_tipo.