Перейти к содержанию

Рекомендуемые сообщения

Доброго времени суток, о светлейшие умы форума, поясните сию приблуду в модели товара, зачем удалять а потом опять записывал, не проще просто обновить запись ? 

$this->db->query("DELETE FROM " . DB_PREFIX . "product_to_store WHERE product_id = '" . (int)$product_id . "'");

if (isset($data['product_store'])) {
  foreach ($data['product_store'] as $store_id) {
    $this->db->query("INSERT INTO " . DB_PREFIX . "product_to_store SET product_id = '" . (int)$product_id . "', store_id = '" . (int)$store_id . "'");
  }
}

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

зачем удалять а потом опять записывал, не проще просто обновить запись ?

Был товар привязан к 10 магазинам (в базе в указанной таблице маппинга - 10 записей), после редактирования - к 4.

Распишите алгоритм, какие записи обновить, какие удалить.

  • +1 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Был товар привязан к 10 магазинам (в базе в указанной таблице маппинга - 10 записей), после редактирования - к 4.

Распишите алгоритм, какие записи обновить, какие удалить.

Вот про это я не подумал, спасибо !

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Распишите алгоритм, какие записи обновить, какие удалить.

 

Пробежаться по циклу селектом и в случае отсутствия удалить/добавить ненужное/нужное..

N запросов + N replace/insert/update

 

Но зачем, если можно удалить ( 1 запрос) а потом N insertов, причем безошибочных

И надо учест, что такие операции не часто делаются., так что беспокоиться об переполнении  int(11) не надо беспокоиться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Почему ж нечасто? При любом редактировании товара - с десяток таких операций. Для магазинов, для категорий, атрибутов, опций и т.п.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Как часто?

Раз в день?

Стоит ли задумываться о... размере id записи, если, грубо, существует foregin key (конечно, не существует)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я же не о размере задумываюсь, а о потерянных записях.

То, что в около-денежном и учётном проекте нет innodb, foreign keys и транзакций - стыдобища, разумеется. Но чинить это даже в масштабах крутой (большой и дружной) сборки - себе дороже.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Как часто?

Раз в день?

Некоторые обожают остатки и цены чуть ли не ежедневно "синхронизировать" через экспорт-эксель-импорт, пересоздавая базу каждый раз. А магазинов с кол-вами меньше пары тысяч товаров я уже давно не видел.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу

×

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.