|
|
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
artemanavadiminfo или сервера приложений. На сервер приложений, работающий со своим клиентом через SQL? И при этом клиент не догадывается к кому он подключен, к серверу БД или к серверу приложений? И у этого сервера приложений, кроме пула коннектов, и зашитой в него бизнес логики, есть еще и самостоятельно поддерживаемый свой кеш данных из центральной БД? И в нем он, по возможности, выполняет SQL-запросы своих клиентов, блокируя их отправку на центральный сервер? Ух ты! Не слышал о таком! Ссылки есть? Если это так, то я признаю что MDT похожа на этот сервер приложений. А так же укажу на то, что систему, включающую такой сервер приложений можно считать системой управления распределенными данными. Чуть ранее я писал, прочтите, если не трудно, какое наполнения я вкладываю в это понятие При работе с сервером приложений клиент подключен к этому серверу приложений, а уже сервер - к одной или десятку БД. То о чем идет речь в теме известно давно, под именем Briefcase. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 14:05 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
iscrafm При работе с сервером приложений клиент подключен к этому серверу приложений, а уже сервер - к одной или десятку БД. Это концептуальное положение понятно и очевидно. Вопрос в том, можно ли считать такой сервер-приложение системой управление распределенными данными? ИМХО, можно, особенно если он работает со своими клиентами посредством чистого SQL и не обязывает их конкретизировать местоположение запрашиваемых источников данных- таблиц, процедур и view. А по вашему? iscrafm То о чем идет речь в теме известно давно, под именем Briefcase. К сожалению не знаком. Я правильно понял из поверхностного чтения, что Briefcase это синхронизация файлов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 14:27 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
artemana, Это "Портфель" из Windows 95 =) Нифига не понял из описания на вашем сайте. Уж подробно так ПОДРОБНО.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 14:29 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
Siemarglartemana, Это "Портфель" из Windows 95 =) Если и да, то гораздо мощнее, но специализация явно уже. Siemargl Нифига не понял из описания на вашем сайте. Уж подробно так ПОДРОБНО.... Ну спроси что нибудь что ли. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 14:33 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
Точнее не "не понял", а "не осилил мого букофф". Подробности как когерентность кэша обеспечивается не вник. Серверах этак на пяти. Глобальные таблицы отслеживания обновлений - не будут ли одним общим тормозом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 14:41 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
artemanaiscrafm При работе с сервером приложений клиент подключен к этому серверу приложений, а уже сервер - к одной или десятку БД. Это концептуальное положение понятно и очевидно. Вопрос в том, можно ли считать такой сервер-приложение системой управление распределенными данными? ИМХО, можно, особенно если он работает со своими клиентами посредством чистого SQL и не обязывает их конкретизировать местоположение запрашиваемых источников данных- таблиц, процедур и view. А по вашему? по моему тоже. По общепринятому, так сказать, определению - тоже iscrafm То о чем идет речь в теме известно давно, под именем Briefcase. К сожалению не знаком. Я правильно понял из поверхностного чтения, что Briefcase это синхронизация файлов?[/quot] да, в общем-то. Это модель, позволяющая клиенту работать с локальными источниками данных, которые, в свою очередь, синхронизируются с центральным сервером(ами). Siemargl конечно же пошутил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 14:41 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
цитирование слетело. правильно так: artemanaiscrafm То о чем идет речь в теме известно давно, под именем Briefcase. К сожалению не знаком. Я правильно понял из поверхностного чтения, что Briefcase это синхронизация файлов? да, в общем-то. Это модель, позволяющая клиенту работать с локальными источниками данных, которые, в свою очередь, синхронизируются с центральным сервером(ами). Siemargl конечно же пошутил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 14:44 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
iscrafmSiemargl конечно же пошутил.Наполовину. Briefcase в левом нижнем углу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 14:44 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
SiemargliscrafmSiemargl конечно же пошутил.Наполовину. Briefcase в левом нижнем углу. речь идет о Briefcase-модели, применительно к обсуждаемой теме. Вы при слове ORACLE на форуме о СУБД провидца не упоминаете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 14:48 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
artemanaНу и в чем и где углядели похожесть? Многопользовательские файл-серверные СУБД так не работают. Они не качают к себе файлы, они самостоятельно и напрямую обрабатывают их (читают, пишут) в том месте, где они размещены (общие файловые шары). Собственно отсюда и все их основные проблемы файл-серверные СУБД находятся на клиенте, и могут только качать к себе данные файл сервера, и у себя выполнять запросы. На основе чего могут и менять сами файлы. Ну как я писал Аксцесса моно юзать в качестве приложения к клиент-серверной СУБД. В общем похожесть в том, что он читает данные из файла, а запросы выполняет у себя. В этом азбучное отличие от клиент серверных, которые на сервере и там же выполняют запросы. artemana На сервер приложений, работающий со своим клиентом через SQL? И при этом клиент не догадывается к кому он подключен, к серверу БД или к серверу приложений? И у этого сервера приложений, кроме пула коннектов, и зашитой в него бизнес логики, есть еще и самостоятельно поддерживаемый свой кеш данных из центральной БД? И в нем он, по возможности, выполняет SQL-запросы своих клиентов, блокируя их отправку на центральный сервер? Ух ты! Не слышал о таком! Ссылки есть? Если это так, то я признаю что MDT похожа на этот сервер приложений. А так же укажу на то, что систему, включающую такой сервер приложений можно считать системой управления распределенными данными. Чуть ранее я писал, прочтите, если не трудно, какое наполнения я вкладываю в это понятие И не тока через SQL. Моно ОЛАПы там строить. Кеш есть. Я Вам писал про Оракловый. Распределенной СУБД это считать нельзя. Это можно считать трехуровневой клиентсерверной архитектурой с сервером прилрожений. А распределенной СУБД Оракл и так является даже в двух уровневой, но с многими локальными БД, в общем случае в разных городах и даже странах и даже космосах. У него ваще есть Грид технология. Там даже встроенный БД могут участвовать. Встроенный в пулеметы на вертолетах. А Вы говорите. Я Вам намекаю, что такие простые идеи реализованы. Я Вам даже намекал куда копать. Но Вы не верите. artemana Теперь понятно. Vadiminfo встретив в тексте слово 'компоненты' не может от него отвязаться. Надо переделывать главную страницу сайта. ;) Думаю не тока я. Без компонентов не сразу буит ясно, что Вы там налабали. А компонты есть - ясно это клиент, либо подобие сервера приложений. Не СУБД же на Дельфи лабать? Если Вы хотитет толкать это как распределенную СУБД не смотря ни на что, то надо убрать слова про Птицу: если она не распределенная, то и у Вас не распределенная. А если распределенная то зачем Вы с Вашими компонентами? Распределенная СУБД должна иметь свое имя как любая СУБД. А Птица с компонетами на Дельфи все равно Птица, как ни крути. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 14:56 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
vadiminfoРаспределенная СУБД должна иметь свое имя как любая СУБД. А Птица с компонетами на Дельфи все равно Птица, как ни крути. а какая часть из той же кучи оракла относится непосредственно к RDBMS? А сколько сверху налеплено, хотя бы и под одним именем? Не вводите в заблуждение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 15:01 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
SiemarglТочнее не "не понял", а "не осилил мого букофф". Подробности как когерентность кэша обеспечивается не вник. Серверах этак на пяти. Глобальные таблицы отслеживания обновлений - не будут ли одним общим тормозом? 1. MDT - обеспечивает синхронизацию центральных данных с локальной копией. Ну почти как портфель, только намного эффективней.;) Это один из основных текущих вариантов, уже почти скоро будет и другая ветка многопользовательских альтернативных копий, но сейчас предлагаю для хоть какой-нибудь ясности ее не цеплять. 2. Центральные данные могут находится как в одной базе так и в нескольких. При этом не должно быть пересечений по именам метаданных. Проще говоря, каждая таблица только в одной центральной БД. Соответственно никакого общего журнала синхронизации нет, в каждой центральной базе он свой. 4. MDT использует максимально эффективное журналирование, согласно которому для логирования операций вставки и изменения записей не выделяется отдельных таблиц. В каждую таблицу добавляется лишь одно целочисленное поле и индекс по нему. Синхронизация выполняется методом приращений (тянуться только новые записи) и только по необходимости, то есть если клиент таблицу "A" не использует, то она у него синхронизировать не будет 3. В случае нескольких центральных БД, MDT-слой (боюсь употребить слово компонента ;), зная положение каждой из них, объединяет все их данные в одну локальную копию и при выполнении на этой копии поступившего от клиента читающего запроса уже не нужно знать, откуда поступили реальные данные, из одной ЦБ или из нескольких. Таким образом одну логическую модель данных приложения, можно в зависимости от требований развернуть на одной или нескольких ЦБ. В любом случае читающие запросы выполняются без использования центральных серверов, что увеличивает пиковую производительность по читающим операциям всей системы в целом прямо порпорционально количеству ее клиентов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 15:13 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
iscrafmvadiminfoРаспределенная СУБД должна иметь свое имя как любая СУБД. А Птица с компонетами на Дельфи все равно Птица, как ни крути. а какая часть из той же кучи оракла относится непосредственно к RDBMS? А сколько сверху налеплено, хотя бы и под одним именем? Не вводите в заблуждение. Ни себя и ни других! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 15:16 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
iscrafmvadiminfoРаспределенная СУБД должна иметь свое имя как любая СУБД. А Птица с компонетами на Дельфи все равно Птица, как ни крути. а какая часть из той же кучи оракла относится непосредственно к RDBMS? А сколько сверху налеплено, хотя бы и под одним именем? Не вводите в заблуждение. Не в курсах какую кучу Вы имеет в виду, и сверху чего и как налеплено. Оракл поддерживает реляционную МД, потому его относят к RDBMS. Если эти парни налабают свое СУБД тада ве равно, что там внутри. Я ему предлагал залезть внутрь Птицы, и там налабать хоть сверхзу, хоть снизу поддержку распределенности. Ну назвал бы распределенная СУБД МТДПТИЦА. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 15:19 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
vadiminfoiscrafmvadiminfoРаспределенная СУБД должна иметь свое имя как любая СУБД. А Птица с компонетами на Дельфи все равно Птица, как ни крути. а какая часть из той же кучи оракла относится непосредственно к RDBMS? А сколько сверху налеплено, хотя бы и под одним именем? Не вводите в заблуждение. Не в курсах какую кучу Вы имеет в виду, и сверху чего и как налеплено. странно. Я думал, что вы специалист по ораклу и знаете его устройство и историю. Ладно, тогда проехали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 15:22 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
iscrafmстранно. Я думал, что вы специалист по ораклу и знаете его устройство и историю. Ладно, тогда проехали. Меньше думать надо, а соображать больше (С) Брат2. Я, например, думал что, Вы тоже не специалист в БД. Мало ли кто о чем думал. Это никак не поможет выдать ему его слой за распределенную СУБД. Вроде, видно же, что это похоже на сервер приложений: он уже сам это слоем назвал. Вот о чем бы Вы луче подумали в этой ветке. А я даже не пользуюсь такими терминами как "устройство" по отношению к Ораклу, тока по отношению к своему авто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 15:31 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
vadiminfoЯ ему предлагал залезть внутрь Птицы, и там налабать хоть сверхзу, хоть снизу поддержку распределенности. Ну назвал бы распределенная СУБД МТДПТИЦА. А Вам еще раз, 3 раз, говорю, что уже залез во внутрь, и поддержку распределенности осуществляет специальная библиотека (dll), заменяющая стандартную из поставки FB. Я понимаю что Вы возможно не знаете как устроено взаимодействие клиента FB с сервером FB, но прошу, поверьте мне на слово - Нет Delphi, нет компонент, а распределенность есть. Кстати название МТДПТИЦА мне понравилось, но лучше поменять местами. Да и вопрос то в другом, летает или не летает, и как будет летать дальше. Для наших потребностей ( www.grossbee.com ) самое то, а как для других сказать не могу - пока нет реальных проектов, увы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 15:37 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
vadiminfoiscrafmстранно. Я думал, что вы специалист по ораклу и знаете его устройство и историю. Ладно, тогда проехали. Меньше думать надо, а соображать больше (С) Брат2. Я, например, думал что, Вы тоже не специалист в БД. Мало ли кто о чем думал. Это никак не поможет выдать ему его слой за распределенную СУБД. Вроде, видно же, что это похоже на сервер приложений: он уже сам это слоем назвал. Вот о чем бы Вы луче подумали в этой ветке. А я даже не пользуюсь такими терминами как "устройство" по отношению к Ораклу, тока по отношению к своему авто. набор слов, да еще и с ошибками. Кто, в том же оракле, делает БД распределенной наверное не в курсе. Ладно, занимайтесь своим авто, не буду мешать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 15:48 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
artemanaА Вам еще раз, 3 раз, говорю, что уже залез во внутрь, и поддержку распределенности осуществляет специальная библиотека (dll), заменяющая стандартную из поставки FB. Я понимаю что Вы возможно не знаете как устроено взаимодействие клиента FB с сервером FB, но прошу, поверьте мне на слово - Нет Delphi, нет компонент, а распределенность есть. Если говорите о распределенной СУБД, то не должно иметь значения взаимодействие клиента с сервером - это взаимодействие серверов БД. Ну так тада Вы типа модифицировали Птицу? Но все за пределами птицы это не относится к управлению распределенностью БД. Такскание на клиентов или куда там данных это другие уровни или там слои - это не управление БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 15:51 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
artemanaSiemarglТочнее не "не понял", а "не осилил мого букофф". Подробности как когерентность кэша обеспечивается не вник. Серверах этак на пяти. Глобальные таблицы отслеживания обновлений - не будут ли одним общим тормозом? 1. MDT - обеспечивает синхронизацию центральных данных с локальной копией. Ну почти как портфель, только намного эффективней.;) Это один из основных текущих вариантов, уже почти скоро будет и другая ветка многопользовательских альтернативных копий, но сейчас предлагаю для хоть какой-нибудь ясности ее не цеплять. Вопрос был "как?". Считал один клиент себе копию и с ней работает только читающими запросами. А другой клиент - изменил в центральной базе. Первый как узнает, что его данные уже устарели? artemana 2. Центральные данные могут находится как в одной базе так и в нескольких. При этом не должно быть пересечений по именам метаданных. Проще говоря, каждая таблица только в одной центральной БД. Соответственно никакого общего журнала синхронизации нет, в каждой центральной базе он свой. Он же один для всех клиентов этой ц.базы. И они конкурентно в него обращаются. Должны мешать друг другу. Интересный эффект как обходится - если данные обновил, полез дописать в журнал и обломился? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 16:03 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
iscrafmнабор слов, да еще и с ошибками. Кто, в том же оракле, делает БД распределенной наверное не в курсе. Ладно, занимайтесь своим авто, не буду мешать. Ваш набор слов про кучи и сверху граматически, возможно, грамотен. Но и только. Не в "том же Оракле делает БД распределенной", а тот же Оракл обеспечиваент управление распределенной БД в соотвествии с некими требованиям, которые позволяют или не позволяют СУБД относить к распределенным. Не важен фрагмент кода, библиотеки: важно как поддерживаетсмя распределенность данной СУБД. Но именно СУБД. А БД то вы можете распределить в сети, клиентом приконектиться к нескольким, выполнить к кажной запрос, а потом в цикле обработать. Это не относят к распределенным СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 16:03 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
vadiminfo Ну так тада Вы типа модифицировали Птицу? Plugin, расширение - эти термины Вам знакомы? vadiminfo Но все за пределами птицы это не относится к управлению распределенностью БД. Такскание на клиентов или куда там данных это другие уровни или там слои - это не управление БД. Очень даже управление и очень даже распределенными данными. Вы спорите, не приведя ни одной ссылки с общепризнанным или авторитетным мнением, на то, что можно считать системой управление распределенными данными, а что нет. Ваше представление в этом вопросе, ИМХО, выглядит так: если все средства (всю систему) управления распределенностью выпустила одна компания и ее имя начинается на О, значит это действительно средства для управление распределенными данными, все остальное на звание "система управление распределенными данными" претендовать не может. Мне грустно-смешно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 16:09 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
SiemarglВопрос был "как?". Считал один клиент себе копию и с ней работает только читающими запросами. А другой клиент - изменил в центральной базе. Первый как узнает, что его данные уже устарели? По мере изменения данных центральной базы активные клиенты получают асинхронные сообщения с данными о том, в каких таблицах и какие операции были сделанны. Siemargl Он же один для всех клиентов этой ц.базы. И они конкурентно в него обращаются. Должны мешать друг другу. Если Вы имеет ввиду взаимные блокировки при одновременном чтении журналов, то их нет в IB\FB\Ya с самого рождения. Siemargl Интересный эффект как обходится - если данные обновил, полез дописать в журнал и обломился? Формирование данных и журналов производится в одной транзакции. Кроме того каждый клиент не формирует журнал самостоятельно, за это отвечаю триггера. И еще кроме того, как я говрил ранее, отдельный журнал (таблица) только для удалений, вставка и изменения отдельнными таблицами не логируется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 16:20 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
artemana, >Если Вы имеет ввиду взаимные блокировки при одновременном чтении журналов, то их нет в IB\FB\Ya с самого рождения. Речь о записи конечно. Со второй попытки дочитал до середины. Основные идеи понял. Все разделяемые таблицы обвешиваются триггерами. Тяжеловато. В общем идея хорошая, но основное ее достоинство в том, что она для IB/FB, где такого нет. Можно ее распространить на другие СУБД без репликации, но их мало. А стандартная поддержка таких решений от вендора Sybase ASA, MS, ORA конечно приятнее для надежности и спокойствия, но не для кошелька ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 16:31 |
|
||
|
СУБД: клиент-серверные и/или распределенные
|
|||
|---|---|---|---|
|
#18+
vadiminfoiscrafmнабор слов, да еще и с ошибками. Кто, в том же оракле, делает БД распределенной наверное не в курсе. Ладно, занимайтесь своим авто, не буду мешать. Ваш набор слов про кучи и сверху граматически, возможно, грамотен. Но и только. Не в "том же Оракле делает БД распределенной", а тот же Оракл обеспечиваент управление распределенной БД в соотвествии с некими требованиям, которые позволяют или не позволяют СУБД относить к распределенным. Не важен фрагмент кода, библиотеки: важно как поддерживаетсмя распределенность данной СУБД. Но именно СУБД. А БД то вы можете распределить в сети, клиентом приконектиться к нескольким, выполнить к кажной запрос, а потом в цикле обработать. Это не относят к распределенным СУБД. бла-бла-бла. Ответьте на простой вопрос: в том же оракле, грид это работа DBMS или целого стека технологий, объединенных по именем оракла? RAC - это DBMS или система "над" Ora..DBMS? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2010, 16:31 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=36828394&tid=1552768]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 259ms |
| total: | 399ms |

| 0 / 0 |
