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

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

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

artemana
Какая разница прикладному слою кто реализует распределенность? Но если не хочешь или не нравятся Delphi компоненты, есть другое решение , на базе специального клиента заменяющего стандартный клиент сервера, настрой для него xml файл и наслаждайся распределенностью. Когда появятся у сервера FB3 другие точки перехвата, будет еще изящнее.

Так можно спросить какая разница прикладному уровню БД там или просто просто данные вфайлах типа Блокнота. Но мы то с Вами догадываемся, что если речь идет об архитектуре,то это имеет значение в общем случае для всех этапов ЖЗ ИС?
Распределенность БД это несколько локальных БД в сети, а то про что Вы это типа толстый клиент закачивает данные к себе. Ну типа аля файл серверная СУБД или сервер приложений. И то и другое есть уже давно.

artemana
Прежде чем давать такие советы надо ознакомится с контекстом, что и почему .

Так вроде же ясно - комроненты качают данные на клиента: такое мы видели. См. выше.

artemana
Я тут не кого не собираюсь удивлять! ТС предложил обсудить тему и я, имея положительный опыт создания и эксплуатации того, что описано в ней, согласился помочь ему.
.

В чем помочь? Написать таки же не просто очередные компоненты? Так мож луче пусть просто Аксцесса возьмет?

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

Так я и назвал концеции похожих технологий. У Вас СУБД: IB\FB\YA, а не некоея распределенная СУБД. Последняя как и все СУБД мало интересуется клиентами, она занимается тока базами распределенными в сети. А у Вас ить на клиента данные лезут? Т.е. у Вас одна локальная БД и толстые типа клиенты.
Это похоже на файл серверную СУБД типа Аксцесса (последний будучи файл серверной СУБД, тем ни менее способен стать клиентом к СУБД типа Скуля в клиентсерверной архитектуре ), либо на серверы приложений.

artemana
Качают многие. Покажите библиотеки обеспечивающие автоматическую, 100 % адекватную синхронизацию данных центральной БД с локальной копией и с автоматическим выполнением на ней читающих SQL запросов.


Не знау, что скрывается у Вас за автоматическим выполнением запросов, но похоже Вы описываете типа сервер приложений (а не распределенную СУБД). Ну там типа кэши хитрые. Соревноваться с ними в синхронизации, это, скорей всего, значит иметь бабки не кислые.
Например, у Оракла есть таковой. Вон семинар буит 15 сентября вроде. Там могли и успросить, что у него 100 процентное, что нет.

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

artemanavadiminfo, я что то перестал понимать о чем Вы спорите и что пытаетесь в данном топике сказать (доказать).
Ну попробую еще, конечно.

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

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

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


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

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

artemana
Теперь понятно. Vadiminfo встретив в тексте слово 'компоненты' не может от него отвязаться. Надо переделывать главную страницу сайта. ;)
Думаю не тока я. Без компонентов не сразу буит ясно, что Вы там налабали. А компонты есть - ясно это клиент, либо подобие сервера приложений. Не СУБД же на Дельфи лабать?
Если Вы хотитет толкать это как распределенную СУБД не смотря ни на что, то надо убрать слова про Птицу: если она не распределенная, то и у Вас не распределенная. А если распределенная то зачем Вы с Вашими компонентами? Распределенная СУБД должна иметь свое имя как любая СУБД. А Птица с компонетами на Дельфи все равно Птица, как ни крути.

iscrafmvadiminfoРаспределенная СУБД должна иметь свое имя как любая СУБД. А Птица с компонетами на Дельфи все равно Птица, как ни крути.
а какая часть из той же кучи оракла относится непосредственно к RDBMS? А сколько сверху налеплено, хотя бы и под одним именем? Не вводите в заблуждение.
Не в курсах какую кучу Вы имеет в виду, и сверху чего и как налеплено. Оракл поддерживает реляционную МД, потому его относят к RDBMS. Если эти парни налабают свое СУБД тада ве равно, что там внутри. Я ему предлагал залезть внутрь Птицы, и там налабать хоть сверхзу, хоть снизу поддержку распределенности. Ну назвал бы распределенная СУБД МТДПТИЦА.

iscrafmстранно. Я думал, что вы специалист по ораклу и знаете его устройство и историю. Ладно, тогда проехали.
Меньше думать надо, а соображать больше (С) Брат2. Я, например, думал что, Вы тоже не специалист в БД. Мало ли кто о чем думал.
Это никак не поможет выдать ему его слой за распределенную СУБД. Вроде, видно же, что это похоже на сервер приложений: он уже сам это слоем назвал. Вот о чем бы Вы луче подумали в этой ветке.
А я даже не пользуюсь такими терминами как "устройство" по отношению к Ораклу, тока по отношению к своему авто.

artemanaА Вам еще раз, 3 раз, говорю, что уже залез во внутрь, и поддержку распределенности осуществляет специальная библиотека (dll), заменяющая стандартную из поставки FB.
Я понимаю что Вы возможно не знаете как устроено взаимодействие клиента FB с сервером FB, но прошу, поверьте мне на слово - Нет Delphi, нет компонент, а распределенность есть.

Если говорите о распределенной СУБД, то не должно иметь значения взаимодействие клиента с сервером - это взаимодействие серверов БД.
Ну так тада Вы типа модифицировали Птицу? Но все за пределами птицы это не относится к управлению распределенностью БД. Такскание на клиентов или куда там данных это другие уровни или там слои - это не управление БД.

iscrafmнабор слов, да еще и с ошибками. Кто, в том же оракле, делает БД распределенной наверное не в курсе. Ладно, занимайтесь своим авто, не буду мешать.
Ваш набор слов про кучи и сверху граматически, возможно, грамотен.
Но и только.
Не в "том же Оракле делает БД распределенной", а тот же Оракл обеспечиваент управление распределенной БД в соотвествии с некими требованиям, которые позволяют или не позволяют СУБД относить к распределенным. Не важен фрагмент кода, библиотеки: важно как поддерживаетсмя распределенность данной СУБД. Но именно СУБД.
А БД то вы можете распределить в сети, клиентом приконектиться к нескольким, выполнить к кажной запрос, а потом в цикле обработать. Это не относят к распределенным СУБД.