Собственно, интересует опыт, идеи в деле переноса базы с одного сайта на другой. К примеру, у клиента был сайт, состряпанный на неизвестно откуда взявшейся CMS, а он желает перенести его на другую CMS. Понятно, что в общем случае задача не решается, но с помощью напильника, какой-то матери и некоторого времени частное решение может быть получено. Еще привлекательней для программирования случай, когда на этой неизвестной CMS было сделано несколько сайтов, которые предстоит перевести в новый вид. В базах довольно дофига довольно уникальной информации, терять, а потом восстанавливать которую очень неприятно 

Для начала - мой опыт этого дела...
Был придуман некий "CMS-независимый вид", который представляет собой простой ассоциативный массив. Каждая уникальная информационная сущность - новости, список юзеров, дерево меню, список статей и т. д. - трансформируется в массив с определенными полями, после чего помещаются в элементы самого "верхнего" массива. пробежавшись по всем сущностям, массив  сериализуется, gzip'уется и объявляется уникальным и неповторимым образом данных сайта. Отдельные пляски ведутся вокруг внутрисайтовых ссылок. В моем случае, каждая ссылка представляла собой ссылку вида "Сущность>>ID", в таком-же виде , примерно, она и остается. Соответственно, каждый элемент каждой сущности помечается собственным ID, чтобы при обратной конвертации можно было найти нужный элемент. 

Для каждой "старой" версии CMC пишется "конвертер" в этот самый CMS-независимый вид. В принципе, достаточно зафиксировать названия и примерный смысл полей "информационных сущностей"...

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

Массив получается примерно такой:

если присмотреться, то можно увидеть, что контент сайта храниться в виде дерева. Каждой веточке дерева может соответствовать "Статья" - элемент items, разные параметры - нецифровые индексы, а также подменю - элементы [0], [1], ...

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

ksnk, я переносил форум

надо посмотреть внимательно структуру таблиц, и придумать как перемещать...

то что отсутсвует можно на ходу прицепить...

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

ты написал дерево, но не понятно как оно в MySQL parrent_id, NestedSet или как-то еще... (скорее всего только parrent_id?)

Это сообщение отредактировал(а) gcc - 19.6.2009, 15:39

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

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

ksnk, тогда я бы тебе предложил в XML структуру хранить. Соответственно импорт, экспорт сделать.
Экспортнул из одной системы, конвертнул ее при помощи XSLT в другой формат и загрузил. Это если простая логика.

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

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

Для 10 страничек действительно нету смысла в програмной конверсии, больше геморою по адаптации конвертера, а вот 40000 товаров и примерно 600 страниц с описаниями - это уже вполне достойная цель 

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

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

Но зато польза хранения "промежуточного" варианта в файле в том, что он занимает один файл. Стер его и порядок на рабочем столе...   

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

Некоторое время назад переделывал свой проект двухгодичной давности, требовалось ускорить работу БД. 
Тоже чего-то сомневался (как бы данные не потерять, база на 500 мегов), выдумывал...

Открываем xxxSQL и ломаем голову над запросами  INSERT ... SELECT ... FROM.

Это сообщение отредактировал(а) eXed - 22.7.2009, 15:12

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

ksnk, как говорится - усложнять легко, упрощать сложно.



Может тогда скриптом генерировать SQL запросы и сохранять их в sql файлик (если данных много)? 
Для nested sets используется phpDBTree?

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

Понятно, что это в какой-то степени самообман  Работы становится меньше только для потока практически одинаковых проектов, а таких, в общем-то, не бывает.

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

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