Sniff-Kadabraпредлагаю обсудить создание "гибридной" субд, включающей в себя как клиент-серверную, так и распределенную части.

Мы уже создали и продолжаем развивать таковую , готов 'обсуждать' ;), что тебя конкретно интересует?

ДжекНепотрошительartemana
Мы уже создали и продолжаем развивать таковую , готов \'обсуждать\' ;), что тебя конкретно интересует?

Это не СУБД, это называется "репликатор"
Ошибаешься.
Так можно что угодно обозвать репликатором, так как репликация, как процесс, присутсвует в любой распределенной системе управления данными.
Подробнее.
P.S.
Не поленись прочитать.

ДжекНепотрошительНе поленился, прочитал. Это действительно репликация, только, ИМХО, чересчур усложненная.
Прочти еще первый пост автора, что он понимает под распределенной СУБД.
И если не согласен, дай свое определение.
В частности интересует чем в твоем представлении распределенная СУБД отличается от MDT, которую ты за систему управления распределенными данымии не считаешь. Каковы в общем случае критерии отделяющие понятия "Распределенная системы управления данными" и "Репликатор"?
ДжекНепотрошитель
Того же эффекта можно было бы добиться и без дополнительных компонент доступа и прослоек, стандартными средствами.
Например?

vadiminfoartemanaВ частности интересует чем в твоем представлении распределенная СУБД отличается от MDT, которую ты за систему управления распределенными данымии не считаешь.
Ну там же написано, что MDT это очередные компоненты к СУБД типа Интербэйс. Т.е. СУБД тут только Интербэйс.
Там как раз написано наоборот, это не просто очередные компоненты к СУБД типа Интербэйс. Пожалуйста, будьте внимательнее,.
vadiminfo
Все остальное типа затычки.
А распределенная СУБД - это, как минимум СУБД.
Т.е. Вам нуно не Дельфишные компоненты лабать, а влезть унурь Интербэйса, и доводить его до распределенной типа СУБД, если Вам нужно именно распределенное СУБД.

Какая разница прикладному слою кто реализует распределенность? Но если не хочешь или не нравятся Delphi компоненты, есть другое решение , на базе специального клиента заменяющего стандартный клиент сервера, настрой для него xml файл и наслаждайся распределенностью. Когда появятся у сервера FB3 другие точки перехвата, будет еще изящнее.
vadiminfo
А луче берите Оракл 10 и выше версии: от типа буковка есть g - Грид: там типа моно лабать сети баз, распределять данные.
А если вам нужно типа сервер(а) приложений с кэшами, то это многоуровневая архитектура.
Если же нужны толстые клиенты как в файлсерврной архитектуре (там просто СУБД на клиентском компе), то берите просто Аксцесс.
Прежде чем давать такие советы надо ознакомится с контекстом, что и почему .
vadiminfo
И не парьтеся с очередным набором комонент: времена када поделками можно было удивить, скорее всего, прошли.
Я тут не кого не собираюсь удивлять! ТС предложил обсудить тему и я, имея положительный опыт создания и эксплуатации того, что описано в ней, согласился помочь ему. Если у Вас есть какие то свои общие вопросы по ней или какие либо конкретные замечания по MDT, присоединяйтесь.

P.S.
То что Оракл - это круто, и там много уже есть и многое будет я и раньше знал, можете не акцентировать.

ДжекНепотрошитель
Распределенная система управления данными - это СУБД, которая поддерживает прозрачную работу с хранилищами, расположенными на разных хостах, обеспечивает обмен данными между хранилищами.

Неплохое определение.
Я бы переформулировал так. Распределенная СУБД проводит не прозрачную, а скрытую работу. Результатом которой, является то, что прикладной слой, его разработчик и пользователь системы, не задумывается о том, как нужно действовать, весь код и функционал клиентской части приложения выглядит так, как будто все данные лежат в одном месте. Вот мой главный критерий.
ДжекНепотрошитель
Репликатор - собственно, тот модуль, который обеспечивает копирование данных из одного хранилища в другое. Может быть одной из компонент распределенной СУБД, может быть автономным приложением.
Почти идеальное определение. Я лишь уточню, что репликатор сам по себе практически никогда не позволяет сделать то, что распределенная СУБД (неизменность прикладного слоя). Рано или поздно система, использующая чистый репликатор, обрастает дополнительным программным кодом, искусственными ограничениями на изменения данный и необходимостью дополнительного мониторинга и администрирования. Одни только конфликты репликации чего стоят.
MDT-технология лишена этих недостатков, позволяет сделать то, что и нормальная распределенная СУБД, и поэтому я считаю что называть ее репликатором неверно.

ДжекНепотрошитель
artemana
ДжекНепотрошитель
Того же эффекта можно было бы добиться и без дополнительных компонент доступа и прослоек, стандартными средствами.
Например?
Стандартные компоненты доступа + IBReplicator, например.
Я убежден,и могу аргументировать, что настройка и эксплуатация MDT легче любого классического репликатора. Например, полностью отсутствует такое понятие как конфликт репликации. Есть и другие пункты.

Кстати, всегда воспринимал IBReplicator относительно производителей сервера как продукт 3-фирмы. Напомни пожалуйста когда он стал штатным средством?

ДжекНепотрошитель
Вообще, нет ничего плохого в том, что вы сделали еще один движок репликации, с дополнительным фреймворком. Может, кому-то и пригодится, в конце-концов, рынок - лучший судья.
И он пока на твоей стороне.
ДжекНепотрошитель
Лично за себя я могу сказать, я бы такое громоздкое решение для утилитарной задачи поддержки локальных хранилищ использовать бы не стал.
Это если самому писать, а если взять готовый за бесплатно или копейки, то почему бы и нет, вполне конкурентное решение, ИМХО.

vadiminfoartemanaТам как раз написано наоборот, это не просто очередные компоненты к СУБД типа Интербэйс. Пожалуйста, будьте внимательнее,.

Ну хоть и не просто, но очередные компоненты? Это ж детали призванные преукрасить положнение дел.

vadiminfo, читать линки будем? Я же указал на то что обеспечивается работа любых приложений использующих IB\FB\YA путем подмены клиенской библотеки сервера.
При таком варианте развертывания компонент нет, как нет и никах изменений в клиентском приложении.
vadiminfo
А мы то с Вами в корень смотрим? А корень - очередные компоненты, ну пусть и не просто, а сложно.

Если бы Вы смотрели в корень, то прежде всего увидел бы не компоненты, а технологию. Обсуждали бы ее достоинства и недостатки. Компоненты или не компоненты - это реализация технологии, и отношение к созданию распределенной СУБД имеет, но не первоочередное.
vadiminfo
Так вроде же ясно - комроненты качают данные на клиента: такое мы видели. См. выше.
Качают многие. Покажите библиотеки обеспечивающие автоматическую, 100 % адекватную синхронизацию данных центральной БД с локальной копией и с автоматическим выполнением на ней читающих SQL запросов.

vadiminfo
artemana
Я тут не кого не собираюсь удивлять! ТС предложил обсудить тему и я, имея положительный опыт создания и эксплуатации того, что описано в ней, согласился помочь ему.
.
В чем помочь? Написать таки же не просто очередные компоненты? Так мож луче пусть просто Аксцесса возьмет?
1. Помочь разобраться
2. Может и лучше. Для некоторых так точно. ;)

vadiminfo, я что то перестал понимать о чем Вы спорите и что пытаетесь в данном топике сказать (доказать). Если не трудно переформулируйте Ваши постулаты с чистого листа.

Моя позиция заключается в том, что если автор интересуется созданием или изучением распределенных СУБД он может, кроме Oracla и все прочего, посмотреть на MDT-технологию, которая реализует определенную свою оригинальную модель управления распределенными данными. Концепции ТС, изложенные в стартовом посте, там однозначно присутствуют. Если какие то из них Вам не нравятся, уточните какие конкретно и почему? И если возможно без простого постулирование, что это и большое, уже есть у Оракла или где то еще, давайте ссылки на средства локального кеширования в 2-звенном клиент-серверном приложение, если у Вас таковые есть.

P.S.
ИМХО.
К сожалению, что такое MDT, как она работает сейчас и что еще будет в нее добавлено Вы, уж извините, ИМХО, не разобрались. Почему - не знаю, но подозреваю потому, что принципиально не верите в то, что что-нибудь новое и полезное, кроме Вам известного, может появиться на свет не от мега-крупных и уже мега-успешных производителей ПО.

P.P.S.
Правда ТС куда пропал и возможно все усилия ни к чему, мы с Вами друг друга не переубедим, а другим так и вовсе не надо.

Вот тут , пункт № 4, еще есть про MDT в виде записи доклада.

vadiminfoО том, что я понял, что у Вас не распределенная СУБД, а Птица, к которой лезут очередные компоненты, чтобы толстые клиенты качали данные с Птичьей БД, и потом запросы к эти данным скаченным у себя там типа выполняли. Это в лучшем случае похожде на файлсерверные СУБД,

Ну и в чем и где углядели похожесть?
Многопользовательские файл-серверные СУБД так не работают. Они не качают к себе файлы, они самостоятельно и напрямую обрабатывают их (читают, пишут) в том месте, где они размещены (общие файловые шары). Собственно отсюда и все их основные проблемы
vadiminfo
или сервера приложений.

На сервер приложений, работающий со своим клиентом через SQL? И при этом клиент не догадывается к кому он подключен, к серверу БД или к серверу приложений? И у этого сервера приложений, кроме пула коннектов, и зашитой в него бизнес логики, есть еще и самостоятельно поддерживаемый свой кеш данных из центральной БД? И в нем он, по возможности, выполняет SQL-запросы своих клиентов, блокируя их отправку на центральный сервер? Ух ты! Не слышал о таком! Ссылки есть? Если это так, то я признаю что MDT похожа на этот сервер приложений. А так же укажу на то, что систему, включающую такой сервер приложений можно считать системой управления распределенными данными. Чуть ранее я писал, прочтите, если не трудно, какое наполнения я вкладываю в это понятие
vadiminfo
Наверное, ТС нуно было тада у них спрашивать про эту типа идею. По крайней мере, они могут отличить, распределенную СУБД, от очередных компонентов. Понятно так? Если нет, то и не знау.
Теперь понятно. Vadiminfo встретив в тексте слово 'компоненты' не может от него отвязаться. Надо переделывать главную страницу сайта. ;)