Качество моделей OpenCart 1.4.8 и ранее

[Shaman]

Сегодня открыл для модификации модель продукта и к своему удивлению обнаружил избыток нелогичных запросов к базе.

Например, с каких пор два запроса DELETE/INSERT к MySQL, да и еще через условие PHP, выполняются быстрее одного UPDATE?

/admin/model/catalog/product.php стр.119-125

		$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 . "'");			}		}

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

И вот еще

/admin/model/catalog/product.php стр.127-154

$this->db->query("DELETE FROM " . DB_PREFIX . "product_option WHERE product_id = '" . (int)$product_id . "'");		$this->db->query("DELETE FROM " . DB_PREFIX . "product_option_description WHERE product_id = '" . (int)$product_id . "'");		$this->db->query("DELETE FROM " . DB_PREFIX . "product_option_value WHERE product_id = '" . (int)$product_id . "'");		$this->db->query("DELETE FROM " . DB_PREFIX . "product_option_value_description WHERE product_id = '" . (int)$product_id . "'");				if (isset($data['product_option'])) {			foreach ($data['product_option'] as $product_option) {				$this->db->query("INSERT INTO " . DB_PREFIX . "product_option SET product_id = '" . (int)$product_id . "', sort_order = '" . (int)$product_option['sort_order'] . "'");								$product_option_id = $this->db->getLastId();								foreach ($product_option['language'] as $language_id => $language) {					$this->db->query("INSERT INTO " . DB_PREFIX . "product_option_description SET product_option_id = '" . (int)$product_option_id . "', language_id = '" . (int)$language_id . "', product_id = '" . (int)$product_id . "', name = '" . $this->db->escape($language['name']) . "'");				}												if (isset($product_option['product_option_value'])) {					foreach ($product_option['product_option_value'] as $product_option_value) {						$this->db->query("INSERT INTO " . DB_PREFIX . "product_option_value SET product_option_id = '" . (int)$product_option_id . "', product_id = '" . (int)$product_id . "', quantity = '" . (int)$product_option_value['quantity'] . "', subtract = '" . (int)$product_option_value['subtract'] . "', price = '" . (float)$product_option_value['price'] . "', prefix = '" . $this->db->escape($product_option_value['prefix']) . "', sort_order = '" . (int)$product_option_value['sort_order'] . "'");										$product_option_value_id = $this->db->getLastId();										foreach ($product_option_value['language'] as $language_id => $language) {							$this->db->query("INSERT INTO " . DB_PREFIX . "product_option_value_description SET product_option_value_id = '" . (int)$product_option_value_id . "', language_id = '" . (int)$language_id . "', product_id = '" . (int)$product_id . "', name = '" . $this->db->escape($language['name']) . "'");						}										}				}			}		}

Это же целая уйма внутрених процессов БД по реорганизации ключей, выполнение которых можно элементарно избежать при этом упростив код.

Можно закрыть глаза на админку. Но если такой код характерен для всего скрипта Open Cart, то складывается впечатление, что разработчики скрипта принебрегают качеством следуя только тенденции "скорости MVC".

Вот такие дела, не выдержал, решил написать сюда, может кто оправдает такой код. Буду рад открыть для себя что-то новое.

[ooZe]

Интересненько :)

[cashfile]

Тебе бы напрямую к Даниелю , разработчику скрипта , обратиться через оф. сайт . Он на такие темы охотно рассматривает и отвечает .

[Shaman]

Попробую когда освобожусь. Хорошо, когда разработчики отзывчивые. Может хоть LIMIT элементарно пороставляют, если полей под 10 тысяч, прилично сократится время запросов.Вообще, скрипт быстро развивается, думаю такие замечания - вопрос времени. Вот был случай, в версии 1.4.7 файл перед удалением не проверялся на наличие, что в отдельных ситуациях вызывало ошибки. Исправил найденные недоработки сам, но когда пришел править этот участок кода в 1.4.8 - увидел уже добавленную проверку. Идейность скрипта хороша, но код не зрелый.

[cashfile]

Попробую когда освобожусь. Хорошо, когда разработчики отзывчивые. Может хоть LIMIT элементарно пороставляют, если полей под 10 тысяч, прилично сократится время запросов.Вообще, скрипт быстро развивается, думаю такие замечания - вопрос времени. Вот был случай, в версии 1.4.7 файл перед удалением не проверялся на наличие, что в отдельных ситуациях вызывало ошибки. Исправил найденные недоработки сам, но когда пришел править этот участок кода в 1.4.8 - увидел уже добавленную проверку. Идейность скрипта хороша, но код не зрелый.

Тем более если ты в этом понимаешь , то есть смысл на подобные недоработки обратить внимание самого разработчика. Единственно что придется с ним общаться через форум оф.сайта и по английски .За скриптом наблюдаю с октября 09 года , и именно с того момента до нашего дня прошло качественное развитие вперед.