Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Estou desenvolvendo um sistema de cadastro de "itens/produtos", existem situações que os itens são mesclados em um novo item.
Se eu tiver o "produto A", "produto B" e "produto A + produto B", quando editar o "produto A" deve afetar o "produto A + produto B"
Eu fiz a seguinte estrutura:
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,ALLOW_INVALID_DATES';
CREATE SCHEMA IF NOT EXISTS `ecommerce` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ;
CREATE TABLE IF NOT EXISTS `ecommerce`.`stock` (
`stock_id` INT(11) NOT NULL AUTO_INCREMENT,
`stock_title` VARCHAR(60) NOT NULL,
`stock_description` VARCHAR(300) NOT NULL,
PRIMARY KEY (`stock_id`))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
CREATE TABLE IF NOT EXISTS `ecommerce`.`poster` (
`poster_id` INT(11) NOT NULL AUTO_INCREMENT,
`poster_price` DOUBLE(9,0) NOT NULL DEFAULT 0,
PRIMARY KEY (`poster_id`))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
CREATE TABLE IF NOT EXISTS `ecommerce`.`attributes` (
`attributes_id` INT(11) NOT NULL AUTO_INCREMENT,
`attributes_title` VARCHAR(45) NOT NULL,
`attributes_value` TINYINT(1) NOT NULL DEFAULT 0,
PRIMARY KEY (`attributes_id`))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
CREATE TABLE IF NOT EXISTS `ecommerce`.`poster_has_stock` (
`poster_poster_id` INT(11) NOT NULL,
`stock_stock_id` INT(11) NOT NULL,
PRIMARY KEY (`poster_poster_id`, `stock_stock_id`),
INDEX `fk_poster_has_stock_stock1_idx` (`stock_stock_id` ASC),
INDEX `fk_poster_has_stock_poster_idx` (`poster_poster_id` ASC),
CONSTRAINT `fk_poster_has_stock_poster`
FOREIGN KEY (`poster_poster_id`)
REFERENCES `ecommerce`.`poster` (`poster_id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_poster_has_stock_stock1`
FOREIGN KEY (`stock_stock_id`)
REFERENCES `ecommerce`.`stock` (`stock_id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
CREATE TABLE IF NOT EXISTS `ecommerce`.`stock_has_attributes` (
`stock_stock_id` INT(11) NOT NULL,
`attributes_attributes_id` INT(11) NOT NULL,
PRIMARY KEY (`stock_stock_id`, `attributes_attributes_id`),
INDEX `fk_stock_has_attributes_attributes1_idx` (`attributes_attributes_id` ASC),
INDEX `fk_stock_has_attributes_stock1_idx` (`stock_stock_id` ASC),
CONSTRAINT `fk_stock_has_attributes_stock1`
FOREIGN KEY (`stock_stock_id`)
REFERENCES `ecommerce`.`stock` (`stock_id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_stock_has_attributes_attributes1`
FOREIGN KEY (`attributes_attributes_id`)
REFERENCES `ecommerce`.`attributes` (`attributes_id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;
Funciona normalmente.
Minha duvida é: Este é a melhor maneira de criar novos itens mesclados a partir de outros itens?
Segue banco completo:
http://www.mediafire.com/download/z21uk2yf8qbsda6/n_m.zip
Mas não existe uma mesclagem "real" eu usei "n:m" (many-to-many), entre as tabelas existe uma outra tabela "poster_has_stock"
Talvez eu esteja confuso. Poderia ser mais claro?
Estou fazendo a consulta assim:
SELECT
`poster_id` AS ID,
`poster_price` AS PRICE,
`stock_title` AS TITLE,
`stock_description` AS DESCRIPTION,
`stock_id` AS STOCK,
`poster_poster_id` AS N,
`stock_stock_id` AS M
FROM
poster A,
stock B,
poster_has_stock C
WHERE
A.poster_id = C.poster_poster_id AND
B.stock_id = C.stock_stock_id
ORDER by poster_id, stock_id
LIMIT 30;
e retorna isto:
+----+-------+-------+-------------+-------+---+---+
| ID | PRICE | TITLE | DESCRIPTION | STOCK | N | M |
+----+-------+-------+-------------+-------+---+---+
| 1 | 5 | A | produto A | 1 | 1 | 1 |
| 2 | 6 | B | produto B | 2 | 2 | 2 |
| 3 | 7 | C | produto C | 3 | 3 | 3 |
| 4 | 8 | D | produto D | 4 | 4 | 4 |
| 5 | 5 | E | produto E | 5 | 5 | 5 |
| 6 | 6 | F | produto F | 6 | 6 | 6 |
| 7 | 10 | A | produto A | 1 | 7 | 1 |
| 7 | 10 | B | produto B | 2 | 7 | 2 |
| 8 | 15 | C | produto C | 3 | 8 | 3 |
| 8 | 15 | D | produto D | 4 | 8 | 4 |
| 8 | 15 | E | produto E | 5 | 8 | 5 |
+----+-------+-------+-------------+-------+---+---+
Usa os joins na sua query, provavelmente atenderá o que você precisa.
Mas a query não é o problema, minha duvida é se a maneira que eu fiz a "estrutura" é o caminho certo para criar produtos "mesclados", por exemplo:
Tenho os seguintes produtos no stock:
Quero anuncia-los separadamente e também "agrupado", combinado com a tabela "poster", terei 3 produtos:
Isto eu consegui, mas quero saber se a maneira que eu fiz é a melhor (usei "n:m"), entendeu?
Você testou os SQLs no download ( http://www.mediafire.com/download/z21uk2yf8qbsda6/n_m.zip )?
Estou tentando entender a estrutura do seu banco.
Você tem o workbench?
Talvez uma imagem ajude:
/applications/core/interface/imageproxy/imageproxy.php?img=http://i.stack.imgur.com/UQ9yN.png&key=6d5df154068398248a14f67a2d966d436ffa3f1ad8f7dc983e0cd496a63663cb" alt="UQ9yN.png" />
Se não entendi errado sua modelagem, creio que está ok essa modelagem.
+1 pelo seu apoio.
Então em "questão" podemos dizer que está é a "melhor maneira" (ou pelo menos uma das melhores) de se fazer isto?
Só para ter certeza.
Não posso simplesmente que é a melhor maneira ou uma das melhores sem conhecer a regra de negócio. Desde que suas tabelas estejam devidamente relacionadas, utilizando-se as formas normais (MER/DER), não há porque dizer que você está fazendo errado.
Entendi o seu ponto de vista e concordo, me perdoe a falta de informações na questão.
A regra é algo como:
Tenho produtos que podem ser vendidos juntos e nisso se tem um desconto (definido pelo vendedor),
por exemplo o vendedor quiser fazer um cesta básica, mas o produto tem que existir no "stock".
Só existe um produto de cada (ou seja cada linha na tabela "stock" são produtos unitários).
São carros e motos de terceiros por exemplo e as vezes o anunciante quer vender o carro e a moto juntos e separados.
Hoje trabalha assim:
id | produto | vendido
----------------------
1 | carro | 0
2 | moto | 1
O anunciante tem 3 anúncios
id_stock | id_poster | produto | vendido
------------------------------------------
1 | 1 | carro | 0
2 | 2 | moto | 1
1 | 3 | carro | 0
2 | 3 | moto | 1
Quando vender, a QUERY vai verificar se existe algum "1", se existir então o produto não aparece, só aparece o produtos com "0"):
id_stock | id_poster | produto | vendido
------------------------------------------
1 | 1 | carro | 0
Essa estrutura e lógica está apropriada?
Muito obrigado!
É uma das maneiras de se fazer e, em uma rápida análise, parece apropriada sim.
Muito obrigado Marcos pela sua atenção e interesse.
Penso que a maneira mais correta para fazer isso, não seria mesclando e sim ter uma tabela de pedidos e outra com os itens do pedido.
Tabela pedidos
| id-pedido(pk) | id-cliente(fk) |
Tabela itens-pedidos
| id-item (pk) | id-pedido (fk) | id-produto (fk) |