ищу инструмент синхронизации. или библиотеку, позволяющую быстро написать под мой конкретный случае инструмент синхронизации.
есть реляционные БД одинаковой структуры. есть механизмы, которые позволяют описать логическую структуру данных(по крайней мере, связь между таблицами, даже не имеющими foreign key): ORM-библиотеки или конфиг в виде xml. 
хочется тулзу, которой: 
а) кормишь описание струтуры
б) кормишь параметры подключения к двум БД
в) тулза проводит сравнение и позволяет выбрать направление переноса данных при несовпадении("синхронизация каталогов" в total commander просто стоит перед глазами )
чего не хватает в имеющихся средствах?
- конфига для сравнения: некоторые поля не нужно сравнивать(modification_time бессмысленно переносить - надо генерировать заново), некоторые поля(значения в них) не надо переносить, логика сравнения может быть сложнее "совпадают/не совпадают значения во всех указанных полях", но все же которую(логику) возможно реализовать в виде sql запроса
- для некоторых записей(которые можно определить при помощи sql-выражения) нельзя делать перенос в направлеини А-В, только наоборот
- некоторые записи зависят от других - если не перенесли запись об объекте, то не давать переносить записи об атрибутах этого объекта
-------------
тут скорее не законченное ПО надо, а платформу/библиотеку.
может, подскажете чего?
[updated]
да, сообщение не совсем было понятно. дополнил первым предложением.

вы ищите ORM?

инструмент синхронизации двух баз данных на уровне объектов, а не отдельных значений в отдельных таблицах.

skyboy, 
посмотри в RoR - миграции. Что-то похожее о чем ты говоришь.

В большинстве же случаев такое пишется ручками насколько я знаю. Ибо все сильно индивидуально.

посмотрю RoR, правда в Ruby даже с синтаксисом незнаком.
насчет "индивидуальности": я вот начал писать и пришел к тому, что есть базовый абстрактный клас с пятком методов, зависящих от структуры, и оболочка, в которой будет большая часть кода и которая не будет привязана к стурктуре.
вот я такое и хотел: написать класс с пятком методов, реализующих выборку/удаление/перенос данных, а все остальное чтоб было.
вот как qsort - передал функцию-callback для сравнения элементов, а невидимый тебе "шаблонный метод" берет на себя обязанность собственно сортировать 
ведь элементов не так уж и много: есть данные в таблице; есть связь между данными; есть набор ограничений, которые можно свести к sql-конструкциям. на самом деле, можно загнать с двух источников данные на локальный сервер и десятком/другим sql-выражений перегнать именно нужные данные.
но это слишком сложно в управлении - изменится структура на одно поле - возможно, придется перелопачивать все сваленные в кучу запросы. а если пропустишь что? и потом порою при переносе нужно просто визуальное сравнение не совпадающих данных, ибо многи параметры не возможно формализировать(например, полнота информации в описании, заносимого автором-человеком) и нужна оболочка для сравнения "визуально".

Добавлено @ 00:05
что-то слишком многословно получилось, извини 

skyboy, можете посмотреть вот эту http://search.cpan.org/search?query=DBIx%3...ss&mode=all

это одна из мощнейших

gcc, я так понял, это ORM написанный на Perl, да?
я там не нашел ничего похожего ни на синхронизацию двух источников данных, ни на импорт/экспорт в XML c древоподобной структурой. Значит, писать самому, пусть и на готовом ORM.

Судя по всему таки миграции.

Суть в том что скрипт миграции описывает две вещи

1. как из состояния А сделать Б
2. как из Б вернуть опять в состояние А

Важно. Это относится именно к структуре (т.е. к полям) с данными.
Эдакая транзакция для структурных изменений.

Пример.

• Меняем структуру с А на Б. (данные перестраиваются)
• Добавляем какие-то данные 1
• Меняем структуру с Б на В. (данные перестраиваются)
• Добавляем данные 2.
• Что-то пошло не так, мы решили откатится.
• Меняем структуру с В на Б. (данные 2 не убирались, а перестраиваются в соответствии с откатом структуры)
• Меняем структуру с Б на Д. (данные перестраиваются)

Добавлено через 5 минут и 26 секунд
Но такие вещи таки пишутся ручками.
Есть у меня одна знакомая, которая занималась практически такими же задачами.
Попробую завтра ее спросить, есть ли у них какой-то специализированный софт для этих задач.

P.S. но если я правильно помню, у них все же работа идет в рамках SQL. Т.е. объектную обвязку тебе надо смотреть/писать отдельно.
Просто я с RoR вообще не знаком, но идею миграций БД мы когда-то брали именно оттуда.

Добавлено через 8 минут и 21 секунду
Забыл уточнить
■Меняем структуру с А на Б
■Меняем структуру с Б на В
■Меняем структуру с В на Б
■Меняем структуру с Б на Д
это все делается скриптами миграций. В итоге ты можешь откатиться без потерь данных в любую точку.

skyboy, тогда не знаю, я преложил посмотреть как вариант

1) с 2 базами можно работать, я с ORM на высоком уроне не работал, но там все красиво на OOP - можно быстро что-то подкрутить, даже OOP на Си переписанном 
2) на счет "синхронизацию двух источников данных" не знаю что это такое... и как именно у вас должно оно быть (догадываюсь)
3) для дерева есть http://search.cpan.org/~bjeps/DBIx-Tree-1.9/Tree.pm
там документацяи не полная, то я выводил (могу показать) в HTML с одим parrent_id все дерево (или начиная с конкертного узла), и с пробелами, красиво, так же выводил в шаблонизатор который очень сильно похож на XML т.е. там реализуемо...

пример вывода дерева на на Rose:B еще тут http://forum.vingrad.ru/index.php?showtopi...t&p=1778273 (почти в виде XML)



Это сообщение отредактировал(а) gcc - 5.1.2010, 02:40

  
хотел уйти от конкретики, чтоб не получить полурешений, но в итоге с абстракциями не справился и только вас запутал 
насчет миграции, Simpliest, я понял. инструмент знакомый. в Doctrine пересекался.
но у меня(черт, почему сразу было не уточнить?!   ) структура не меняются. Только данные.
Пример:
есть БД с каталогом предприятий. есть внутренняя база и каталог на сайте. Редактироваться данные могут независимо друг от друга(потому односторонний перегон данных "локальная БД->сайт" не устроит). И надо время от времени производить синхронизацию.
Некоторые поля заменяться не должны, некоторые предварительно должны быть проверены человеком(на сайте при вводе проверка помягче и могут попадаться даже откровенно ложные данные, что допустимо для сайта и недопустимо для внутренней БД) - потому репликация, даже двухсторонняя, не подходит.
Вот и я пытался найти существующее решение, которое позволило бы свести операцию синхронизации к той, что есть в файловых менеджерах:
выбрать источники(папки == базы данных)
выбрать алгоритм сравнения(файлы можно сравнивать побайтово, а вот для БД может понадобиться описать алгоритм, игнорирующий некоторые различия)
выбрать направление копирования(слева-направо, справа-налево, удалить слева, удалить справа) 
выполнить синхронизацию(перенос файлов/операции над данными в БД).
в конечном итоге написал инструмент на РНР, где логика сравнения/переноса для каждой сущности в БД инкапсулирована в определенный класс. А остальное - платформа(что я собственно искал) реализует визуальный интерфейс и абстрактные файлы, которые надо реализовать для определения логики работы.

skyboy, такого нет.

У тебя целостность данных вынесена в приложение и приложением же тебе разруливать. Структура твоего приложения - одному богу известна. И в общем случае ни один парсер не позволит однозначно ее определить (для частных случаев опять таки пишутся обычно индивидуальные вещи  )

Выхода у тебя 2.
1. Писать контроль целостности данных в виде отдельной части приложения (тогда ты можешь этим же контролем и пользоваться при экспорте/импорте)
2. переделать базу, возложив контроль целостности на нее.

Добавлено через 22 секунды
собственно, ты по первому пути и пошел 

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

ясно. спасибо.