У меня есть стол с именем orders_products
которые содержат все продукты, связанные с каждым отдельным заказом. Теперь, если покупатель решит отредактировать количество, атрибуты или просто удалить товар, какой будет самый простой способ справиться с этим изменением в базе данных?
orders_products
id | quantity | fk_products_id | attributes | price | fk_orders_nr
fk_products_id
относится к фактическому идентификатору продукта в нашей таблице продуктов
attributes
является разделенной запятыми строкой с идентификатором id в нашей таблице атрибутов (атрибуты могут быть углом, длиной, диаметром и т. д. для каждого продукта. Как и в 45 градусах, левый ангел, 20 см в длину, 43 мм в диаметре).
fk_orders_nr
фактический заказ, к которому относится товар.
Так как у меня есть class
который обрабатывает эту часть на стороне клиента. Будет ли проще просто DELETE
все сопутствующие товары на основе идентификатора заказа (fk_orders_nr
), и просто заново вставить и обновить весь набор на основе того, что хранится в классе?
Или есть удобный способ справиться с этим непосредственно в MySQL?
Я немного посмотрел on duplicate key update
, а также ignore
, но они, кажется, не соответствуют моим потребностям ..
Мне нужно проверить, существует ли фактический идентификатор продукта, затем принять решение вставить новый или обновить существующий (это могут быть как количественные, так и / или необязательные атрибуты), а также продукт может быть удален, если его нет в списке из class
больше.
При написании этого вопроса. Я думаю, что удаление всего набора и его повторная вставка могут быть самым простым способом.
Эта база данных выглядит плохо разработанной. Во-первых, я предполагаю, fk_products_id
ты имеешь в виду product_id
, Вам не нужно указывать, что столбец является внешним ключом в своем имени.
Во-вторых, я бы посоветовал вам сохранять все столбцы атомарными, как, например, без множественных значений. attributes
столбец с разделенным запятыми списком вызовет у вас головную боль в будущем, а также сломает Первая нормальная форма (самый основной).
В-третьих, вам не нужно (хотя иногда это может быть полезно) id
в качестве первичного ключа в вашей соединительной таблице. Вы можете просто использовать составной первичный ключ из вашего fk_products_id
а также fk_orders_nr
ключи.
При написании этого вопроса. Я думаю, удалив весь набор, и
вставьте его, возможно, самый простой способ.
Да, так обычно и делают.
Но я настоять вы игнорируете все о текущей проблеме и переконструировать Ваша база данных с нуля, уделяя особое внимание нормализация. Это основной стандарты проектирования баз данных, и они существуют по определенной причине. Надеюсь, вы не узнаете о причине, когда уже слишком поздно.
Других решений пока нет …