Как правильно обновлять таблицу многие ко многим?

Question

[Heinemann]

Какой подход использовать в обновлении таблицы многие ко многим?
Я в размышлениях столкнулся с ситуацией, что нет необходимости в такой таблице использовать Update
Почему:
Если нам нужно изменить ранее заданные связи, например, у товара есть 2 фильтра, то нам нужно явно передать в where старые id фильтров, иначе получится вот так:

UPDATE products, product_category, product_filter
SET products.name ='Платок',
products.price='3459.00',
products.description='Белый платок',
product_category.category_id='2',
product_filter.filter_id='1',
product_filter.filter_id='2'
WHERE products.id='2' AND product_category.product_id='2' AND product_filter.product_id='2'

Если же нам нужно удалить один из фильтров, а второй обновить, то нам необходимо провести две операции: delete и update, передавая в update id старого фильтра, который мы хотим обновить.

И так мы получаем минимум две ситуации, где sql будет сильно отличатся, плюс потребность передавать id старых записей.

Третий же вариант - мы просто удаляем все записи, а потом вставляем новые.

UPDATE products, product_category
SET products.name ='Платок',
products.price='3459.00',
products.description='Белый платок',
product_category.category_id='2'
WHERE products.id='2' AND product_category.product_id='2';
DELETE * FROM product_filter 
WHERE product_id='2';
INSERT INTO product_filter
(filter_id, product_id) VALUES ('1', '2'), ('2', '2')

У меня пока еще слабые знания в sql, потому хочу узнать "правильный" подход с точки зрения семантики и реализации.

Comments

[Akina]

Добавьте исходные данные - в виде online fiddle, или хотя бы как CREATE TABLE + INSERT INTO. Покажите входные данные и требуемое конечное состояние для них, с детальными пояснениями.

хочу узнать "правильный" подход

Правильно - не валить всё в кучу. Корректируйте каждый фильтр отдельно и безотносительно к остальным.
Если же на клиенте формируется не изменение, а финальное состояние, то подход "всё удалить и новое вставить" - и правилен, и гораздо проще.

[alexalexes]

Судя по тексту запроса, у вас все поля строкового типа.
Допустим, за что провинились идентификаторы и поле цены, что вы не хотите их сделать числовым типом?
Или просто везде кавычки понаписали, не думая что за тип данных?

[Heinemann]

alexalexes, Спасибо, что подметили. Кавычки у меня вошли в привычку после использования конструкций implode("','", array_keys($products))
Думал, что sql не принципиально, если числовый тип оформлять кавычками в качестве значений. Если я не прав, поправьте.

[Heinemann]

Akina, Я больше хотел узнать о правильном подходе в изменении таблицы многие ко многим, нежели в помощи составления для меня запроса, потому и не приложил исходные данные. В любом случае мысль я вашу понял, спасибо.

[alexalexes]

Вообще, запрос не должен выполнятся, если перепутали строку и число в константных значениях.
Скорее всего у вас поля таблиц не тех типов, нужно смотреть структуру таблицы (что было в запросе create table).
Чем это грозит.
Будут неправильно работать сортировки по якобы числовым полям (order by id - получили результат '1', '10', '2', '200', '3' - что-то пошло не так?), неэффективно использоваться индексы по этом полям, невозможно будет провести математические операции без преобразования строки внутри одного запроса (а попробуйте при таком типе сделать update, накинув сверху 100 ед цены, не тягая значение из varchar в numeric и обратно? вот так:
update products
set price = price + 100
where id = 2
не получается? ).

[Heinemann]

alexalexes,
Вот структура таблицы продукт. А запрос ваш успешно выполнился)

CREATE TABLE `products` (
  `id` int NOT NULL AUTO_INCREMENT,
  `name` varchar(250) NOT NULL,
  `description` text,
  `price` decimal(10,2) NOT NULL,
  `img` varchar(250) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8mb3

[Heinemann]

alexalexes, Да, я знаком с возможными последствиями, о которых Вы написали, но, как я уже сказал ранее, мне думалось, что sql не столь важно, в кавычкам мы передаем число или нет. Надо будет почитать об этом)