[Resolvido] Relacionamento múltiplo (?)

[Matias Rezende 50]

Fala galera... Tudo certo?

 

Hoje sou eu aqui pedindo ajuda... Tenho 2 tabelas no banco (noticia e portfolio).

 

O problema:

 

Preciso que seja possível definir destaques entre estas duas tabelas. Ou seja, o usuário do sistema poderá escolher 2 destaques, sendo possível 2 noticias, 2 portfolios ou 1 de cada. Na hora de modelar o banco, só consegui pensar em algo assim:

 

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';


-- -----------------------------------------------------
-- Table `noticia`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `noticia` (
 `noticiaId` MEDIUMINT(8) NOT NULL AUTO_INCREMENT ,
 `noticiaTitulo` VARCHAR(100) NOT NULL ,
 PRIMARY KEY (`noticiaId`) )
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `portfolio`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `portfolio` (
 `portfolioId` MEDIUMINT(8) NOT NULL AUTO_INCREMENT ,
 `portfolioTitulo` VARCHAR(100) NOT NULL ,
 PRIMARY KEY (`portfolioId`) )
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `destaque`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `destaque` (
 `destaqueId` MEDIUMINT(8) NOT NULL AUTO_INCREMENT ,
 `noticiaId` MEDIUMINT(8) NULL ,
 `portfolioId` MEDIUMINT(8) NULL ,
 PRIMARY KEY (`destaqueId`) ,
 INDEX `fk_destaque_noticia` (`noticiaId` ASC) ,
 INDEX `fk_destaque_portfolio1` (`portfolioId` ASC) ,
 CONSTRAINT `fk_destaque_noticia`
   FOREIGN KEY (`noticiaId` )
   REFERENCES `noticia` (`noticiaId` )
   ON DELETE CASCADE
   ON UPDATE CASCADE,
 CONSTRAINT `fk_destaque_portfolio1`
   FOREIGN KEY (`portfolioId` )
   REFERENCES `portfolio` (`portfolioId` )
   ON DELETE CASCADE
   ON UPDATE CASCADE)
ENGINE = InnoDB;



SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

 

Achei meio "feio" fazer assim, mas foi a melhor opção que achei. Não consegui achar nada na internet sobre o assunto (provavelmente porque não sei o termo certo pra procurar), então resolvi perguntar para os amigos aqui.

 

Esta é a melhor opção? Se não for, qual seria?

 

Obrigado!!!

 

Carlos Eduardo

 

PS : Os campos da tabela de noticias e portfólio não são só estes. Aí foi só pra exemplo.

[Motta 645]

Um Destaque não poderia ter 2 Noticias por este modelo ?!

 

Apenas um de cada.

[Matias Rezende 50]

Na verdade não. Imaginando que tenhamos as notícias 1, 2, 3 e 4 e os portfolios 1, 2, 3, e 4, e que eu queira definir que o portfólio 1 e a noticia 1 sejam destaques. Ficaria, na tabela de destaques algo assim: (vai ficar meio estranho pq eu to digitando no iPod)

 

1 1 0

1 0 1

 

Então, para buscar os dados eu faria o Join entre as tabelas normalmente, cada um com seu campo.

 

Assim seria a melhor forma?

 

Carlos Eduardo

[Motta 645]

Mas como um destaque teria 2 notícias ?!

[Matias Rezende 50]

Pegando o exemplo de cima, imaginando que eu queira a notícia 2 e 4 como destaque:

destaqueId | noticiaId | portfolioId
   1      |     2     |    NULL
   2      |     4     |    NULL

 

Captou como estou querendo fazer? Assim funciona perfeitamente, mas estou na dúvida se é a melhor opção.

 

Carlos Eduardo

[Motta 645]

Não vejo maiores problemas então, melhor que usar flags para sinalizar uma ou outra tabela.

 

Apenas a regra de 2 notícias/portifólios e que deve ser gerenciada pela aplicação.

[Matias Rezende 50]

Não vejo maiores problemas então, melhor que usar flags para sinalizar uma ou outra tabela.

Eu não gosto muito de usar flags (pelo jeito você também não é muito fã... :)). Este foi um dos motivos pelos quais eu pensei em fazer assim. Poderia ter adicionado um campo em cada uma das tabelas e definido via flag em cada registro. Mas achei que assim era mais "elegante".

 

Apenas a regra de 2 notícias/portifólios e que deve ser gerenciada pela aplicação.

Exatamente. Com esta modelagem, eu tenho a possibilidade de colocar quantas novidades forem necessárias sem modificar o banco. Se hoje são 2, tudo bem. Se amanhã o cliente quiser permitir 5, a aplicação dá conta disto também.

 

Valeu Motta!!!

 

RESOLVIDO