Предпологаю, что задача не травиальная, и свиду несовсем разумно воспринимаемая, но надо попытатся реализовать
Схема:

Художник из меня никакой, знаю.
1. Юзер передаёт запрос на апп сервер, ПХП скрипту
2. пхп скрипт формирует SQL запрос и отправляет его псевдо SQL серверу.
3. Псевдо SQL сервер смотрит на скольких MySQL серверах разкиданны данные, после чего посылает на каждый из них по запросу
4. Дожидается ответа ото всех, после чего комбинирует результаты так, как будто всё пришло одним куском
5. Псевдо SQL  сервер отдаёт апп серверу готовые данные, в соответствие с запросом, который апп. посылал, всё лишние выкидывается, все параметры учитываются
6. на основе полученных данных, апп сервер генерирует ответ и отправляет юзеру.



Из этого всего, я больше всего не знаю как сделать две вещи:
1. скомбинировать данные, и обработать их повторно, с наименьшими потерями времени и наименьшей нагрузкой на псевдо сервер
2. передать данные обратно апп так, чтоб тот принял их за SQL query

 Ну расширяешь свой класс базы под работу с этим чудом, в чем проблемы то?
Только если ты застрял в 2000 голу и используешь mysql_функции, но не делай так просто, давно придумали ООП. Сразу преимущество видишь? 
Первый пункт не понял.

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

Это академическая задача?

А так не знаю есть ли это в мускуле (сомневаюсь). А вот в FireBird это реализуется средствами самого сервера firebird.

Добавлено через 19 секунд
Да. Firberd начиная с версии 2.5

Absinthe, Это всё придумано, как раз таки, что бы избежать репликации



voral, Нет это задача реальная, для проекта. Пойду почитаю про firebird

Почитал про firebird не нашёл про решение задачи, только про то, что база может быть до 64терабайт, и находится в разных файлах, а про лежать на разных серверах ничего не стоит

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

http://forum.vingrad.ru/forum/topic-280164...1%81%D1%8B.html

voral, 

По сылки выборка из удалённой базы, это немного не то.

Попытаюсь описать пример:

Сервер А - апп сервер с пхп скриптами, к нему обращается юзер
Сервер Б - для сервера А выглядит как ДБ сервер, но по факту там тоже пхп
сервер В,Г,Д - ДБ сервера с mysql на них.

Общия таблица на скажем 300.000 строк записей, делится по определённому признаку, и по третям разкладывается на сервера В,Г,Д.
Сервер А иммет таблицу, где указано, при каких условиях, сколько таблиц задействовано.
Если условия выборки затрагивают только один ДБ-сервер, сервер А посылает туда запрос на прямую.
Если же затрагиваются несколько ДБ-серверов, то сервер А посылает на сервер Б запрос в том виде, как будто бы на сервере Б была база содержащия информацию из всех трёх частей.
Сервер Б, получая информацию от сервера А, так же смотрит по признакам, в каких ДБ-серверах находится подходящия информация, и разсылает туда запросы.
Получив все (допустим три) ответа, задача сервера Б собрать всё воединно, ещё раз сделать сортировку данных, по заданным параметрам, и отдать их серверу А.

Все просто. У вас есть скрипт который обрабатывает запросы пользователя.  Этот скрипт производит запросы к одной специальной БД.
Ведь выборку можно делать не только из таблиц, но и процедур.
В этой специальной БД. Есть перечень всех БД с рабочими данными, есть признаки, что и где искать в соответствии с вашим ТЗ.
Именно в этой БД. Храниться "таблица, где указано, при каких условиях, сколько таблиц задействовано". Т.е. можно вообще все возложить на  эту специальную БД. 
К сожалению сам я сейчас делаю смежную задачу (этим занимался мой друг. Я где то через недельку плотно буду этим заниматься) и вот прям конкретно не могу расписать.

Я просто не знаю ваш уровень владения - на всякий случай: вы знаете о хранимых процедурах? О "EXECUTE STATEMENT " ?

Т.е. вы можете объединить данные из разных бд, можете даже предварительно обработать и отправить в ответ на запрос из php-скрипта Для которого это будет как совершенно обычная база. 



Это сообщение отредактировал(а) voral - 23.7.2011, 23:26

мои познания не велики, INSERT SELECT DELETE UPDATE, создавать и изменять превык в phpmyadmin, с индексами разобрался, типы данных стараюсь подбирать к колонкам максимально эффективно. Поэтому мне нужно просто, и надёжно, как калашников ))

Топикстартер, может все-таки ты напишешь свою задачу?
Тогда и поможем.

Тут важно понять. Что пхп скриптовый язык, серевер на нем не написать. Хотя псевдо можно . Первый скрипт пишет запрос в файл или БД, второй ("сервер") запускается по расписанию читает и обращается к БД, пишет в файл ответ..... бррррр. жутко долго, ненадежно и геморно.

При обращении к веб-странице пользователь дергает скрипт, этот скрипт дергает другой скрипт и тот запрашивает данные у БД). Еси дергать второй скрипт "дергать" какимто html запросом - жуткое извращение, если просто инклудить. ТО это будет, по сути, один скрипт и разделять его на два файла имеет смысл только в случае необходимости для всей системы в целом (т.е. если этот второй файл используется еще каким то скриптом)

Ну а если нужно "просто, надежно". И решение твое задачи. То SQL сервер FireBird 2.5+   Изучаем его возможности (точнее возможности языка PSQL). Изучаем коллекцию php функций по работе с этим сервером. Вроде c префиксом ibase_  (т.к. в свое время FireBird клонировался от Interbase). В замен phpMyAdmin берем IBExpert (он для exUSSR бесплатен)  Только придется перегонять данные из мускуля.


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

Absinthe, 
Задача: спроектировать и написать систему, которую можно будет маштабировать в почти что не ограниченных размерах


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


Я часть задачи для себя решил, осталось одно "Как эффективние сделать склейку нескольких запросов и повторную очистку, по начальному запросу".

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

BASILIO, насколько я понял, речь о шардинге. Статья в тему. Если описанные там варианты не подходят, то опишите чем именно. Если же вопрос в том, как это реализовать на стороне PHP, то ваш псевдосервер, обычно. является частью ORM (уже на уровне ORM прописывается какие значения брать с каких серверов).

Но вообще Absinthe прав -- для того, чтобы что-то советовать, нужно знать задачу, а не только то, как вы ее собираетесь решать. Чем вызвано использование нескольких серверов? Снижение нагрузки, или просто так исторически сложилось? Почему не походит репликация master-master?

solenko, 1. Спасибо за ссылку
2. мой вариант находится тут: "горизонтальный шардинг"
3. Моя проблема в том, что имея части таблицы на разных серверах, надо делать на них выборки, сводить полученные данные в одно целое, после чего повторить выборку.



Пример:

Таблица с 20-ю колонками, большая часть INT.
Таблица настолько велика (чисто образно 100м записей), что разнесена ан 3 физических сервера.
1. Надо послать на все 3 сервера, одинаковый запрос, на выбоку с кучей логики <, >, NOT, IN, limit допустим 30.
2. Нам приходит 3x30 строк в ответ
3. Нам надо из это сделать одну "таблицу", и выбрать первые 30, в зависимости по чему "Order by"


Как лутче всего это реализовать?