Oi, bimonti! Tudo bem?
Bom... Antes de lhe dar a solução para o seu problema, vou te explicar algumas coisas sobre relacionamento de tabelas.
Vc já deve ter ouvido falar que existem alguns tipos de relacionamentos, ditos "1 para muitos", "muitos para 1", "1 para 1" e "muitos para muitos". Se não ouviu falar, fique tranqüilo. Eu explico.
Imagine a seguinte situação: uma tabela para guardar várias empresas existentes e uma tabela para guardar todos os funcionários de todas as empresas. Cada uma possui dados específicos de cada objeto, ou seja, tabela de empresas guarda tudo de cada empresa (nome, endereço, CNPJ, etc, etc, etc), e tabela de funcionários guarda tudo, também (nome, endereço, telefone, CPF, etc).
Se quisermos relacionar estas duas tabelas, temos duas opções. Depende de que lado vamos enxergar os dados. Calma q vc vai entender...
Se observarmos a relação a partir da empresa, então vemos que cada empresa pode ter muitos funcionários. Vemos assim, a relação um para muitos (uma empresa ligada a muitos funcionários). Agora, se observarmos a relação a partir do funcionário, vemos que cada funcionário está ligado a uma e somente uma empresa. Ou seja, temos a relação um para um (um funcionário para uma empresa).
Agora entenda... Toda vez que tivermos uma relação um para um, ou muitos para um, então basta criar um campo na tabela de origem. Ou seja... Enxergue a relação funcionário - um para um - empresa. Como estamos observando pelo funcionário, então a gente fala de um campo na tabela funcionários. Bastaria, para resolver o problema de relações, acrescentar um campo na tabela funcionário para dizer a que empresa ele pertence.
Mas se observarmos pela empresa do meu exemplo e vermos que a relação é de um para muitos (uma empresa para muitos funcionários) ou, se em algum caso enxergarmos uma relação muitos para muitos (vou mostrar depois que este é o seu caso), então a gente precisa de uma tabela intermediária.
Para explicar este último parágrafo, vou entrar no seu exemplo pra vc ver, na prática, como funciona.
Em seu problema nós temos uma tabela de empresas e uma tabela de categorias. Se cada empresa pudesse estar em somente uma categoria (como vc chegou a citar), então a relação seria de 1 para 1 e bastaria criarmos na tabela empresas um campo pra dizer qual é a categoria a qual ela pertence. No entanto, uma empresa pode ter mais de uma categoria, então temos a relação de um para muitos.
Vamos começar a enxergar dos dois lados. Cada empresa pode ter diversas categorias (observando do lado da empresa), e cada categoria pode estar associada a diversas empresas (observando do lado da categoria). Desta forma, temos uma relação de muitos para muitos.
Vamos, desta forma, criar uma tabela intermediária para resolver nosso problema.
Teremos, no final das contas, uma tabela com os dados da empresa:
- nome
- cod_empresa
- endereco
Outra tabela com os dados das categorias:
- cod_categoria
- titulo
A tabela intermediária fará a relação muitos para muitos que necessitamos. Vou nomeá-la empresas_cats, mas pode colocar o nome q vc achar melhor. Seus campos:
- cod_empresa
- cod_categoria
Ambos estes campos serão chave, para que nunca exista duplicidade no cadastro de uma mesma empresa para uma mesma categoria. E, além disto, serão chaves estrangeiras.
No MySql, cria-se esta relação da seguinte forma:
CREATE TABLE empresas_cats (
empresa_id int(3) not null,
categoria_id int(3) not null,
primary key(empresa_id, categoria_id),
foreign key (empresa_id) references empresas(id),
foreign key(categoria_id) references categorias(id)
);
Se vc quiser, pode também adicionar regras de eventos para cada chave estrangeira. Um evento é um DELETE ou um UPDATE, por exemplo. Repare: suponhamos que tenhamos a empresa de ID=4 e de nome "Empresa X". Suponhamos que na tabela empresas_cats, este ID esteja associado com as categorias de IDs 2 e 3. Então, existe isto:
SELECT id,nome FROM empresas WHERE empresa_id=4;
|---------------------|
| id | nome |
|---------------------|
| 4 | Empresa X |
|---------------------|
SELECT * FROM empresas_cats WHERE empresa_id=4;
|--------------------------------|
| empresa_id | categoria_id |
|--------------------------------|
| 4 | 2 |
| 4 | 3 |
|--------------------------------|
Se vc fizer um DELETE na tabela empresas e apagar a empresa de ID=4, na tabela empresas_cats ainda existirão aquelas referências vagas, certo? Estarão lá referenciando as categorias 2 e 3 com uma empresa que não existe.
Para corrigir isto, podemos, por exemplo, criar a chave estrangeira dizendo que, no evento apagar o registro na tabela pai (empresas), os registros filho associados na tabela filho (empresas_cats) sejam também apagados. Este processo chama-se apagar em cascata. Ou então, ao invés de apagar em cascata, podemos associar ao evento ON DELETE a ação de fazer com que os registros filhos fiquem nulos, ou algumas outras ações. Para fazer a ação apagar em cascata associada ao evento ON DELETE, devemos escrever isto na hora de criar a tabela:
CREATE TABLE empresas_cats (
empresa_id int(3) not null,
categoria_id int(3) not null,
primary key(empresa_id, categoria_id),
foreign key (empresa_id) references empresas(id) ON DELETE CASCADE,
foreign key(categoria_id) references categorias(id) ON DELETE CASCADE
);
Vc pode fazer o mesmo para ações de UPDATE, também.
Para ver maiores informações, leia este endereço:
http://dev.mysql.com...onstraints.htmlEspero ter ajudado em sua questão. Qualquer dúvida, basta perguntar!
Um abraço,
Thales Medeiros.
