Работа с двумя базами одновременно.

[Aectann]

Работа с двумя базами одновременно.

Вообщем то вот такой вопрос:
У меня есть большая система, где хранение информации должно быть разбито на 2 базы - 1-ая общяя информация (персоны, обьекты, сделки), 2-ая - контактная информация (привязана к записям 1-ой базы). Фактически - это одна база, разнесенная на разные физические сервера. все это реализуется на MySQL 5.
Если кто уже сталкивался - подскажите, как правельно организовать запросы и синхронизацию? То что мне приходит на ум - примитивно (вставить запись в основную, получить вставленый ID, подключится к дополнительной, вставить запись туда, отключится), хотя все гениальное - просто .
Вообщем у кого есть мысли - то поделитесь.

 

[si]

обычная репликация встроенная в mysql вам не подходит ?

 

[voituk]

Вариант первый - репликация

Вариант второй - Использовать введенный в 5-м MySQL Federated storage engine http://dev.mysql.com/doc/refman/5.0/en/federated-storage-engine.html

 

[Aectann]

Я про реплекацию думал, но плохо знаю этот механизм..
вот видимо пришло время узнать получше
Спасибо, буду ковырятся в указанных направлениях..

 

[Апельсин]

si, у него не дублирование, а именно разнесение на разные сервера. Стандартная репликация не то ..

 

[shefeduard]

а ты делай 2 запроса...
сначало к первой - возьми все нужные переменые...
подключайся ко всторой и выводи другие по первым...

вот только при конструировании таблиц надо всегда узакывать

в первой базе id - это порядковый (персоны, объекта и т.д.)

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

а дальше в скрипта очень легко будет отсортировать...

 

[Aectann]

Ну я в принципе так и думал делать в начале (я там написал в начале, может не совсем понятно), просто думал - может есть другие варианты.
Federated storage engine - вроде ничего, но при создании таблиц нужно строго указывать какая таблица(хост,юзер и т.п.) к ней конектится, но настройки не останутся такие как есть на стадии разработки.
Вообщем как всегда придется изобретать велосипед...

 

[shefeduard]

ну в этом и есть суть програмирования))
из одной вещи делаем 2) только чтобы это не вредило серваку))
иначе бы программирование было бы скучным)...

 

[voituk]

о настройки не останутся такие как есть на стадии разработки

А ALTER TABLE при развертывании приложения слабо сделать?

 

[Aectann]

Автор оригинала: voituk
А ALTER TABLE при развертывании приложения слабо сделать?

Если бы все это было разовым явлением, то конечно можно - поставил, настроил и забыл. Но все должно быть многоразово и автономно.

 

[voituk]

Aectann
А репликация в таком случае не будет настраиваться "многоразово и автономно"?

 

[Aectann]

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

 

[si]

Aectann
если честно я до конца не смог понять что вам нужно