Em vez de
review_autosave_data você pode criar duas tabelas como review_insert_drafts e review_update_drafts (um para novas revisões e outro para atualizações de revisão). CREATE TABLE `review_insert_drafts` (
`product_id` int(11) unsigned NOT NULL,
`user_id` int(11) unsigned NOT NULL,
`review` blob,
`name` varchar(100) DEFAULT NULL,
PRIMARY KEY (`product_id`, `user_id`),
CONSTRAINT FOREIGN KEY (`product_id`) REFERENCES `products` (`id`),
CONSTRAINT FOREIGN KEY (`user_id`) REFERENCES `users` (`id`)
);
CREATE TABLE `review_update_drafts` (
`review_id` int(11) unsigned NOT NULL,
`review` blob,
`name` varchar(100) DEFAULT NULL,
PRIMARY KEY (`review_id`),
CONSTRAINT FOREIGN KEY (`review_id`) REFERENCES `reviews` (`id`)
);
(Não tenho certeza do que o
name coluna é bom para.) Em seu aplicativo, você deve verificar se o usuário está escrevendo uma nova avaliação ou atualizando uma existente.
Para novas revisões, você executa:
INSERT INTO review_insert_drafts (product_id, user_id, review)
VALUES (50, 1, "lorem ipsum")
ON DUPLICATE KEY
UPDATE review = "lorem ipsum";
ou
REPLACE INTO review_insert_drafts (product_id, user_id, review)
VALUES (50, 1, "lorem ipsum");
Para atualizações de revisão, você executa:
INSERT INTO review_update_drafts (review_id, review)
VALUES (25, "lorem ipsum")
ON DUPLICATE KEY
UPDATE review = "lorem ipsum";
ou
REPLACE INTO review_update_drafts (review_id, review)
VALUES (25, "lorem ipsum");
Vantagens:Você tem um design claro com chaves exclusivas claras e chaves estrangeiras.
Desvantagens:Você tem duas tabelas contendo dados semelhantes. Então você tem duas instruções de inserção diferentes. E você precisará de uma instrução UNION se quiser combinar as duas tabelas (por exemplo, mostrar todos os rascunhos para um usuário).
