UMI.CMS - история одного ужаса. Или как мне пришлось переносить данные из ЮМИ на Opencart

категория: , Полезности


Опубликовано: 01.11.2018 Обновлено: 17.11.2018 Просмотров: 1481 Комментарии: 9


UMI.CMS - история одного ужаса. Или как мне пришлось переносить данные из ЮМИ на Opencart

Как мне "посчастливилось" пощупать UMI CMS особенно со стороны переноса данных и почему меня до сих пор тошнит при слове UMI


Часто ко мне приходят проекты по переносу данных из любых движков или самописов на Opencart. Это я люблю делать и с удовольствием выполняю. Но в этот раз что-то пошло не так.. Надо было перенести данные из UMI CMS. Не смотрев в базу, структуру, мы договорились о работе о чем очень жалею. Почему? Об это далее.

UMI CMS и структура базы данных

Как мы знаем во всех нормальных CMS к которым и относится Opencart структура базы очень простая и понятная. Все по своим таблицам, везде есть id и этот id можно узнать прямо в админке в исходном коде - все как надо. Но в ЮМИ у нас нет дифференциации на товары, категории, заказы. Все там в одну кучу скинуто в пару таблиц с миллионные записями.. Ох..

UMI - база данных

При этом если просто зайти через phpmyadmin в таблицу мы увидим что-то страшное

UMI trash

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

UMI all

А если еще зайти на 16483 страницу то будет например такое

UMI таблицы а базе данных

То есть как видим все в куче и в непонятной форме/структуре.

Кстати там разработчики постебались знатно. Пол базы занимают поля для "подготовки экспорта" или импорта. Вроде в админке экспорт, а в базе импорт. Что это вообще такое? Зачем все данные сайта пихать в кучу в подготовленные данные для выгрузки в отдельные таблицы??? Такого бреда я не видел еще. ЮМИ побил все рекорды по мазохизму.

UMI

А еще разработчикам показалось что в базе должно быть больше таблиц и они решили сделать мега супер статистику и выделить под нее пол базы, если не больше. Зачем?

UMI CMS

Из 96 таблиц в базе  "статистика" занимает всего 35 таблиц, а я тут сказал уже что половину, не прав. :-D Кстати, а разработчики знают что есть например такое как google analitics в котором все отлично и он не увеличивает вашу базу в гектары? Хм.. видимо нет.

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

UMI DB

А еще давайте зайдем в базу UMI cms3_objects и мы видим опять же эти наборы несвязанных данных в куче с другими

UMI baza

Ну и как тут, извините, не стошнит?

Про админку вообще молчу, это что-то страшное и непонятное. Например все связи выставлены через непонятный через связей id. То есть нет прямой связи. Есть поле которое подвязывается под объект (а это может быть все что угодно) и этот объект связан с другим объектом как-то не ясно как.

Я эти данные еле перенес и то не все. Часто я связи вообще не мог найти. Что употребляют разработчики данного движка не ясно. Но очень не рекомендую связываться с UMI вообще ни за какие деньги. Вы валерьянки больше скушаете))


Комментарии:


Фото комментатора

Лучший 18.11.2018

Когда-то работал с юми. Жесть еще та. Надо было на сайте мелочи настроить, так пока все нашел что где находится - проклял все. Опен куда более проще и лучше. Работаю с ним недавно но уже много что могу сделать, очень простой движок
Администратор

Ответ for-opencart.com 18.11.2018

Согласен
Фото комментатора

Александр 11.02.2019

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

Ответ for-opencart.com 11.02.2019

Ох, сочувствую.. Сам еле еле перенес данные через одно место как говорится.
Фото комментатора

Александр 11.02.2019

А можно у вас спросить, как у бывалово, так сказать) Мне бы лучше всего выгрузить в YML, он всё таки стандартизирован. Но в него выгружаются не все товары - как я понимаю, дело в том, что у некоторых количество нулевое(Но это не точно). Как бы мне так увеличить количество у всех товаров? Или просто выгрузить в YML все товары? Как вариант ещё в CSV, но в CSV почему-то не выгружаются категории.. Всё что там есть это некий "id родительской страницы" с которым хрен пойми что делать. Как вообще у вас получилось выгрузить? Я уже сижу волосы на себе рву..С какими только движками не работал, такого не встречал. Больше не буду никогда ругаться на джумлу)
Администратор

Ответ for-opencart.com 11.02.2019

Точно не помню, но если есть возможность выгрузить все в xml или yml или excel конечно выгружайте. Уже как есть данные в нормальном виде то любой файл по сути обработать не проблема. Я выгружал через одно место. Там надо было еще выгружать мне цены групп покупателей вот я намучился. Я выгружал и через xml и через csv и через базу а также просто выводят результат в браузер (делал там запрос на юми) и сохранял результат в файл потом файл парсил. Просто пробуйте разные варианты. У меня например ушло около недели на все это, или больше, уже не помню, но было очень люто, очень.
Фото комментатора

Михаил 25.02.2019

О боже, после увиденного юми сразу в блэклист. Навсегда.
Фото комментатора

Сергей 14.06.2019

Модель хранения данных иерархических типов и объектов, которая используется в UMI, называется EAV. Да, она имеет свои ограничения и недостатки, но в данном случае, это лучший вариант хранения данных. Брюзжать и уж тем более поливать грязью, из-за того что вы не разбираетесь в чём-то, как минимум непрофессионально. В UMI.CMS, помимо модуля обмена данными, есть мощный функционал выборок, с помощью которого можно сформировать список товаров и сохранить его в любом удобном для вас формате. Вывод - банальная некомпетентность автора вылилась в поток обвинений разработчиков системы.
Администратор

Ответ for-opencart.com 14.06.2019

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

Alex 17.06.2019

Спасибо, за информацию! ) Поддерживаю Михаила - в блэклист. В Open Cart, множество задач администрирования можно сделать только запросами на MySQL без кодирования. И это благодаря простой структуре баз данных. А от Сергея, эмоционально отреагировавшего на заслуженную критику, хотелось бы развернутого аргументирования в пользу EAV - "в данном случае, это лучший вариант хранения данных" - особенно вот об этом. )
Администратор

Ответ for-opencart.com 17.06.2019

+++ Кстати почитал я за EAV и не понял в чем его преимущество кроме создания головняка разработчикам и пользователям. Ведь с таким подходом что неизвестно сколько будет полей а сохранить надо прекрасно можно обойтись без EAV, например как сделаны атрибуты, опции и т.п. Может конечно что-то непонимаю, но ЮМИ в топку из-за ненужной сложности.
Фото комментатора

Алексей 16.07.2019

Пара слов в поддержку UMI: 1. У UMI действительно все данные хранятся в паре таблиц, которые действительно могут быть достаточно большими. В этом есть свои плюсы и минусы. Из плюсов: не нужно знать в какой таблице и как хранятся те или иные данные. Не нужно вообще "лезть" в mysql. Все данные можно и нужно достать с помощью API 2. В UMI.CMS есть экспорт и импорт данных. Достаточно удобный, кстати. Таблицы с "import" в названии нужны для интеграции с внешними системами. Чтобы сопоставить импортируемые данные с существующими. 3. Статистика легко отключается галочкой в админке. Старую статистику можно очистить одной кнопкой. Каждый решает сам - нужна ему она или нет. Не вижу причины ругать CMS за наличие отключаемого функционала. 4. Все связи действительно осуществляются через ID. Большинство сущностей системы - это объекты, имеющие уникальный ID. Не понимаю, что в этом нелогичного. PS На вкус и цвет все CMS разные. Я давно и плотно работаю с UMI. Пробовал соскочить - не получилось: находил в других системах безумные косяки и неудобства. Плюс в UMI есть доступ к разработчикам ядра (при определенных условиях, конечно). Можно оперативно решить вопрос. Мало какой IT продукт может этим похвастаться.
Администратор

Ответ for-opencart.com 16.07.2019

Спасибо за развернутый комментарий. 1) Ну здесь я согласен есть как плюсы так и минусы. Но все же в точки зрения понимания это большой минус. 2) Есть, да, но я в нем не разобрался и он на том сайте просто не работал выдавал ошибку скрипта. 3) За статистику не знал, все верно говорите. 4) Мне там все нелогично, может из-за того что привык к простоте и прозрачности Opencart. Ну каждый работает в том что ему заходит что и логично. Но мне UMI совсем не зашел.
Фото комментатора

Сергей 20.08.2019

"А от Сергея, эмоционально отреагировавшего на заслуженную критику, хотелось бы развернутого аргументирования в пользу EAV - "в данном случае, это лучший вариант хранения данных" - особенно вот об этом. )" Да без проблем) Допустим у нас есть Зоо-интернет-магазин. В нём есть несколько типов товаров и типов данных для них: Хомячок, Клетка и Колесо. Тип данных "Хомячок" имеет 4 поля - возраст, пол, вес. Тип данных "Клетка" имеет 4 поля - длинна, высота, ширина, цвет. Тип данных "Колесо" имеет 2 поля - радиус и материал. Да, можно хранить такую схему в "плоских таблицах". Но потом руководство интернет-магазина решило расширить ассортимент и стали продавать рыбок, корм для рыбок, аквариумы и аксессуары для аквариумов. Окей, ещё пара-тройка таблиц...а потом? Вот здесь-то EAV и выигрывает у "плоских таблиц". У каждого типа может быть свой набор полей, этих типов может быть сколько угодно и ограничивает всё это только фантазия. Я не являюсь адептом модели EAV и не призываю использовать её везде где только можно, но считаю что в случае с интернет-магазином, где есть множество типов товаров, со своими уникальными характеристиками, она подходит лучше всего.
Администратор

Ответ for-opencart.com 20.08.2019

Ну смотрите гораздо же проще сделано в opencart где есть атрибуты и их группы. То есть можно либо добавлять атрибуты и их писать в характеристиках либо добавить свои атриуты в свою группу. Как по мне это более удобно чем использовать EAV
Фото комментатора

Константин 29.08.2019

Школотроны, которые топят за "прекрасный современный EAV" не имеют понятия про нормальные формы. Это как сравнивать каталог с разделами и кучу хлама в шкафу, где лежат молоток, картошка и грязные носки на одной полке. Когда ты создал на коленке интернет-магазин с тремя товарами и считаешь себя разработчиком - это UMI. В моём магазине десятки тысяч товаров и этот дебильный подход - вообще не вариант для нагруженных сайтов. Таблица в гигабайты размером? Я на хостинге разорюсь. Сергей вообще не понимает, о чём говорит. Тип данных "хомячок"... первая таблица: код товара, название товара (хомячок) вторая таблица: код товара, код характеристики третья таблица: код характеристики, название характеристики (вес), описание характеристики (вес в граммах) количество строк в таблицах не ограничено Любую сущность можно так описать. Это оптимизация. Это экономия ресурсов. А школоло нам предлагает свалить всё в кучу и каждый раз при поиске перетрахивать всю гигабайтную таблицу. Не хватает ресурсов на тарифном плане? Надо ввалить ещё денег. Вот и все варианты у тупней с дивными новыми технологиями "неплоских таблиц".

Быстрый поиск

Похожее

Новое на сайте