Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > PHP: Для профи > Перенос базы (всего сайта) с одной CMS на другую

Автор: ksnk 18.6.2009, 08:38

Собственно, интересует опыт, идеи в деле переноса базы с одного сайта на другой. К примеру, у клиента был сайт, состряпанный на неизвестно откуда взявшейся CMS, а он желает перенести его на другую CMS. Понятно, что в общем случае задача не решается, но с помощью напильника, какой-то матери и некоторого времени частное решение может быть получено. Еще привлекательней для программирования случай, когда на этой неизвестной CMS было сделано несколько сайтов, которые предстоит перевести в новый вид. В базах довольно дофига довольно уникальной информации, терять, а потом восстанавливать которую очень неприятно  Для начала - мой опыт этого дела... Был придуман некий "CMS-независимый вид", который представляет собой простой ассоциативный массив. Каждая уникальная информационная сущность - новости, список юзеров, дерево меню, список статей и т. д. - трансформируется в массив с определенными полями, после чего помещаются в элементы самого "верхнего" массива. пробежавшись по всем сущностям, массив  сериализуется, gzip'уется и объявляется уникальным и неповторимым образом данных сайта. Отдельные пляски ведутся вокруг внутрисайтовых ссылок. В моем случае, каждая ссылка представляла собой ссылку вида "Сущность>>ID", в таком-же виде , примерно, она и остается. Соответственно, каждый элемент каждой сущности помечается собственным ID, чтобы при обратной конвертации можно было найти нужный элемент.  Для каждой "старой" версии CMC пишется "конвертер" в этот самый CMS-независимый вид. В принципе, достаточно зафиксировать названия и примерный смысл полей "информационных сущностей"... Для каждой "новой" версии CMS, в которую переносим данные, пишется обратный конвертер. В зависимости от настроения, можно, было бы, наверное даже старый вид ссылок оставить без изменения, но вообще говоря база заново пересоздается, с новым распределением строк в таблицах, так что производится поиск и "разрешение внутрисайтовых" ссылок... еще немного магии и практически все готово ... Массив получается примерно такой: Код Array (     [content] => Array     (             [razdel] => 2             [name] => main             [items] => Array             (                 [0] => Array                 (                     [type] => textpic                     [text] => ' Уважаемые покупатели...'                 )                 [1] => Array                 (                     [type] => href                     [column] => 1                     [0] => Array                         (                             [type] => link                             [name] => link                             [item_url] => prais.xls                             [item_text] => Скачать прайс-лист                         )                 )                 [type] => article              )             [descr] => Основные разделы             [0] => Array                 (                     [razdel] => 4                     [name] => О компании                     [items] => Array ...     [users] => Array         (             [0] => Array                 (                     [id] => 2                     [cust_EMAIL] => [email protected]                     [cust_FIO] => Just a Name                     [cust_TYPE] => 1                     [password] => ?????????                     [right] => admin                     [name] => admin                 ) ... если присмотреться, то можно увидеть, что контент сайта храниться в виде дерева. Каждой веточке дерева может соответствовать "Статья" - элемент items, разные параметры - нецифровые индексы, а также подменю - элементы [0], [1], ... Понятно, что процесс туда-сюда конверсии, как правило, небыстр и делать его имеет смысл только на локальном сервере, в тепличных условиях, имея под рукой подходящих размеров кувалду...

Автор: gcc 19.6.2009, 15:36

ksnk, я переносил форум надо посмотреть внимательно структуру таблиц, и придумать как перемещать... то что отсутсвует можно на ходу прицепить... тестировать - пробовать, как правило может что-то не сработает, аваторки, вложение файловые ты написал дерево, но не понятно как оно в MySQL parrent_id, NestedSet или как-то еще... (скорее всего только parrent_id?)

Автор: ksnk 19.6.2009, 16:46

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

Автор: IZ@TOP 25.6.2009, 19:16

ksnk, тогда я бы тебе предложил в XML структуру хранить. Соответственно импорт, экспорт сделать. Экспортнул из одной системы, конвертнул ее при помощи XSLT в другой формат и загрузил. Это если простая логика. По хорошему, необходимости в конвертации быть не должно. Если только у тебя клиент не решил перейти, например, с Битрикса на твою систему. И то, даже в этом случае, возможно, ему будет дешевле свои 15 страничек и 50 наименований из прайса перебить руками, чем платить за это деньги.

Автор: ksnk 26.6.2009, 00:29

IZ@TOP, XSLT, imho, имеет смысл использовать, если где-то между экспортом и импортом сидит кто-то, кто этот формат как-то может использовать. У меня пока php на одной стороне и php на другой, так что надобности в каком-то формате, кроме родной php-шной сериализации не вижу... Вот если сайт будет сделан на чем-то трудновыразимом средствами PHP, тогда можно подумать о более универсальном формате... Для 10 страничек действительно нету смысла в програмной конверсии, больше геморою по адаптации конвертера, а вот 40000 товаров и примерно 600 страниц с описаниями - это уже вполне достойная цель

Автор: gcc 15.7.2009, 16:14

ksnk, я бы поставил это дерево в MySQL и использровал например Nestetset...

Автор: ksnk 15.7.2009, 16:20

gcc, Что-то в этом есть. К примеру для достаточно большой базы упаковка данных в сериализованную строку может занять достаточно много памяти. Сейчас я открутил лимиты дл моего локального PHP аж на 512 метров... Но зато польза хранения "промежуточного" варианта в файле в том, что он занимает один файл. Стер его и порядок на рабочем столе...

Автор: eXed 22.7.2009, 15:11

Дико извиняюсь, если обижу ваше конг-фу, но когда речь идет о данных в БД, то проще всего написать несколько запросов приводящих все в нужный вид. Некоторое время назад переделывал свой проект двухгодичной давности, требовалось ускорить работу БД.  Тоже чего-то сомневался (как бы данные не потерять, база на 500 мегов), выдумывал... Открываем xxxSQL и ломаем голову над запросами  INSERT ... SELECT ... FROM.

Автор: ksnk 22.7.2009, 17:20

eXed, База у мены кардинально меняется. Из непонятно какого дерева делается nested sets.  Задача не особо тривиальная для простого INSERT ... SELECT ... FROM ;-)

Автор: eXed 23.7.2009, 03:55

ksnk, как говорится - усложнять легко, упрощать сложно. Цитата Задача не особо тривиальная для простого INSERT ... SELECT ... FROM ;-) Может тогда скриптом генерировать SQL запросы и сохранять их в sql файлик (если данных много)?  Для nested sets используется http://dev.e-taller.net/dbtree/?

Автор: ksnk 23.7.2009, 05:45

eXed, еще определенная польза в том, что проектов много, и потенциальных проблем с переездом на новый формат может возникнуть тоже много. Если придумать относительно "базонезависимый" вид хранения контента, то в принципе, для каждого проекта остается только немного "откоректировать напильником" конвертер в это "базонезависимый". А уж из него уже как-бы уже один раз пишется конвертер в текущую версию. Работа как-бы сокращается в ~2 раза... Понятно, что это в какой-то степени самообман  Работы становится меньше только для потока практически одинаковых проектов, а таких, в общем-то, не бывает. Понятно также, что большие объемы данных (каталоги магазинов) в мой формат физически не влезут. Столько памяти в машине может и не быть установлено. Но каталоги, собственно, практически без изменений кочуют из проекта в проект sql-импортом. Чего там менять-то?

Автор: MoLeX 10.2.2010, 06:58

Автор: awers 16.2.2010, 00:56

Автор: cha0t1k 13.4.2010, 22:11

Как раз сейчас занимаюсь переносом сайта на новый движок соответственно с совершенно другой структурой базы. Перенос контента, и файлов. В общей сумме 1.5 миллиона записей в 3 таблицах(контент). связанных между собой,  плюс файлы, хранящиеся по алгоритму высчитывания папки хранения по id(математически причем).   Для себя пришел к выводу что в рамках ограниченного времени, лучше всего система из трех частей - гейты для получения данных из старой базы, вместе со связями, гейты вставки в новую базу с новыми связями. По сути все можно делать на моделях(если ОРМ), или просто дергать функции/методы старой и новой системы. Третье звено, промежуточное, реализует взаимодейтсвие между этими сущностями,т.е. управляет моделями, или дергает функции/методы старой и новой системы, ну или же написанные с нуля, оптимизированные запросы. В некотором роде mapper.  Еще есть фактор нагрузки на систему. По приблизительным расчетам в моем случае перенос займет 30-40 часов при полной нагрузке на сервер(все происходит локально). Что позволит нельзя, поэтому переносить имеет смысл небольшим числом записей за раз с отлаженной задержкой, чтобы старый сайт продолжал нормально отвечать на запросы пользователей.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)