Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
 Re: СУБД: клиент-серверные и/или распределенные  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
iv_an_ru
Хорошо подумали ???
Плохо подумал. Действительно, не прошло и двадцати лет, как фраза устарела.


Она никогда и не была актуальной.
Что-же до гробокопательства, то им здесь позанимались совсем другие люди

P.S. Но я рад, что Вы понимаете, что подумали плохо :)
6 сен 10, 09:30    [9387531]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
vadiminfo
Вот правило 0 Дейта:
С точки зрения конечного пользователя распределенная система должна выглядеть в точности так, как обычная, не распределенная система.
Правила Кодда у Вас есть, надеюсь. Сравните, плиз 0-левые, если совпадут бум проверять первое.

Наконец то.
Именно, соблюдение этого правила, которое я привел еще первой на первой странице, дает мне право на использование термина "Распределенная СУБД" по отношению к MDТ.
Давайте, проверяйте остальные.

И прекратите третировать термин "компоненты", я Вам не поленюсь в 4 раз повторить, в определенном варинате развертывание Firebird с MDT их нет. Можете это если не понять или проверить, то хотя бы поверить в это?

А где все таки ссылки, очень хотелось бы восполнить пробел, в отношении мифических 12 правил Дейта?
6 сен 10, 11:59    [9388771]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
artemana
очень хотелось бы восполнить пробел, в отношении мифических 12 правил Дейта?

LMGIFY.

Локальная автономность. Локальные данные должны находиться под локальным владением и управлением, включая функции безопасности, целостности, представления данных в памяти. Исключением может быть ситуация, когда ограничения целостности охватывают данные нескольких узлов или когда управление распределенной транзакцией осуществляется некоторым внешним узлом.
Никакой конкретный сервис не должен возлагаться на какой-либо специально выделенный центральный узел. Соблюдение этого правила, т.е. принципа децентрализированности функций РСУБД, позволяет избежать узких мест.
Непрерывность функционирования. Система не должна останавливаться в случае необходимости добавления нового узла или удаления в распределенной среде некоторых данных, изменения определения метаданных и даже (что довольно сложно) осуществления перехода к новой версии СУБД на отдельном узле.
Независимость от местоположения. Пользователи и приложения не обязаны знать о том, где физически располагаются данные.
Независимость от фрагментации. Фрагменты (называемые также разделами) данных должны поддерживаться и обрабатываться средствами РСУБД таким образом, чтобы пользователи или приложения могли бы вообще ничего не знать об этом. Более того, РСУБД должна уметь обходить при обработке запросов фрагменты, не имеющие к ним отношения.
Независимость от тиражирования. Те же принципы независимости и прозрачности относятся и к механизму тиражирования.
Распределенная обработка запросов. Обработка запросов должна производиться распределенным образом.
Управление распределенными транзакциями. На распределенные базы данных необходимо распространить механизмы управления транзакциями и управления одновременным доступом. Эта проблема включает выявление и разрешение тупиковых ситуаций, прерывания по истечении временных интервалов, фиксацию и откат распределенных транзакций, а также ряд других вопросов.
Независимость от оборудования. Одно и то же программное обеспечение РСУБД должно выполняться на различных аппаратных платформах и функционировать в системе в качестве равноправного партнера. На практике достичь этого исключительно сложно, поскольку многие поставщики поддерживают множество платформ. Это ограничение преодолевается с помощью модели много-продуктовых сред.
Независимость от операционных систем. Эта проблема тесно связана с предыдущей, и она также разрешается аналогичным образом.
Независимость от сети. Узлы могут быть связаны между собой с помощью множества разнообразных сетевых и коммуникационных средств. Многоуровневая модель, присущая многим современным информационным системам (например, семиуровневая модель OSI, модель TCP/IP, уровни SNA и DECnet), обеспечивает решение этой проблемы не только в среде РБД, но и для информационных систем вообще.
Независимость от СУБД. Локальные СУБД должны иметь возможность участвовать в функционировании РСУБД.

Но как только нужна производительность, из этих правил сразу начинаются многочисленные исключения :)
6 сен 10, 12:43    [9389209]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
iv_an_ru, Спасибо, эти правила я читал, но не знал, что их называют 12 правилами Дейта.
Последнее действительно так?
6 сен 10, 13:22    [9389570]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
artemana

Именно, соблюдение этого правила, которое я привел еще первой на первой странице, дает мне право на использование термина "Распределенная СУБД" по отношению к MDТ.
Давайте, проверяйте остальные.

Вы никак не обращаете вниманеие на то, чтобы говорить о том, что у Вас есть распределенная СУБД, нуно чтобы у Вас была сама СУБД. Мы знаем что Вы юзаете Птицу: но она типа не у Вас: не Ваше детище.
Кроме того, хотел бы обратить внимание на то, что если у Вас СУБД, то все вопросы про закачивание данных к клиенту, скорей всего, не входят в ея круг обязанностей, если речь идет в клиент серверной сетевой архитектуре. Поскоку клиенты там на отличных от сервервера БД уровнях, а все управление данными типа на уровне сервера БД.
А раз Вы с Птицей дело имеете, то у Вас клиент сервеная ожидается, мне кажется.
Т.е. все пока выглядит так, что Вам нуно мало того, что СУБД заиметь, так еще отказаться от толстых клиентов. Или отделить их и говорить про них отдельно от управления рспределенной БД. Например, про распределенные вычисления (вместо управления распределенной БД), если Вам нуно сохранить обязательно слово "распределенный".

artemana

И прекратите третировать термин "компоненты", я Вам не поленюсь в 4 раз повторить, в определенном варинате развертывание Firebird с MDT их нет. Можете это если не понять или проверить, то хотя бы поверить в это?

Ну, возможно, я не совсем виноват, что этот термин так для Вас звучит в моих текстах. Но я и другие и, судя по всему Вы, относятся скептически к очередным компонентам. Вы же сами писали "не просто очередные компоненты". Значит просто очередные вызывают у Вас настороженность? Ну я не множко шире посмотрел - у меня и не просто очередные тоже вызвали.

artemana

А где все таки ссылки, очень хотелось бы восполнить пробел, в отношении мифических 12 правил Дейта?

Я же дал название книги. У Вас был курс БД? Там же должны были читать. Это же все избитые весчи. Впрочем, про них я упомянул чтобы уточнить, что вообще говоря существуют требования к распределенным СУБД, а не уклончивом "определенном варинате развертывание Firebird с MDT", ну и тем более не просто очередных компонентах.
Если бы у Вас была своя собственная распеределенная СУБД, то лично меня бы, скорее всего, интересовало тока сравнение с Ораклом (или там Скулем - другой лидирующей СУБД).


Но до требований мы вообше не дошли: я просто так и не понял что у Вас есть своя СУБД, а если есть, то зачем Вы говорили о закачке данных на клиенотов, т.е. о делах клиентских, ну пусь сервер приложенческих.
6 сен 10, 16:31    [9391729]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
vadiminfo
artemana

Именно, соблюдение этого правила, которое я привел еще первой на первой странице, дает мне право на использование термина "Распределенная СУБД" по отношению к MDТ.
Давайте, проверяйте остальные.

Вы никак не обращаете вниманеие на то, чтобы говорить о том, что у Вас есть распределенная СУБД, нуно чтобы у Вас была сама СУБД. Мы знаем что Вы юзаете Птицу: но она типа не у Вас: не Ваше детище.

По определению, система - это что то, состоящие из нескольких элементов, простых или сложных. Система, любая система, не обязательно состоит только из элементов произведенных одной командой или компанией.

Но Вы с упорством, достойным лучшего применения, пытаетесь опровергнуть эти очевидные утверждения. Так как по Вашему выходит, что если Firebird не принадлежит нам, а MDT не принадлежит владельца Firebird (IT-сообществу), то работоспособный комплекс из этих двух элементов, нельзя назвать системой управление распределенными данными. Это, наверно, 13 правило Дейта?
6 сен 10, 17:46    [9392627]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
vadiminfo
вообще говоря существуют требования к распределенным СУБД, а не уклончивом "определенном варинате развертывание Firebird с MDT", ну и тем более не просто очередных компонентах.

а можно эти требования опубликовать? Или имеется ввиду частное мнение Дейты на этот счет?
6 сен 10, 17:58    [9392752]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
имхо, уже откровенный бред пошел. Ничего личного, vadiminfo, заканчивайте.
6 сен 10, 18:00    [9392786]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
artemana
По определению, система - это что то, состоящие из нескольких элементов, простых или сложных. Система, любая система, не обязательно состоит только из элементов произведенных одной командой или компанией.

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

artemana

Но Вы с упорством, достойным лучшего применения, пытаетесь опровергнуть эти очевидные утверждения.

Я вообще не рассуждал ни о каких элементах. Просил тока Вас объявить что Вы модифицировали элементы систему Firebird и получили новую СУБД.

artemana

Так как по Вашему выходит, что если Firebird не принадлежит нам, а MDT не принадлежит владельца Firebird (IT-сообществу), то работоспособный комплекс из этих двух элементов, нельзя назвать системой управление распределенными данными. Это, наверно, 13 правило Дейта?

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

Если можно назвать этот работоспособный комплекс распределенной СУБД, то называйте. Имя иму давайте. Я ж Вам предлагал. Вам даже понравилось, но Вы не назвали. Про толстых клиентов закачку на них данных забывайте, если, конечно, Ваш комлекс не стал файл серверной СУБД. Читайте про требования к распределенным СУБД. Для приличия правила Дейта уж стоит почитать. Выполнять не обязательно.
6 сен 10, 19:50    [9393463]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
iscrafm
имхо, уже откровенный бред пошел. Ничего личного, vadiminfo, заканчивайте.

Я тоже о Ваших текстах чрезмероно низкого мнения, но рот Вам не затыкаю. Подозреваю что это у Вас личное.
6 сен 10, 19:53    [9393473]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54761

vadiminfo

Это наверное, будет все еще ИС - система, но СУБД то может остаться все та же Птица.
Остальные не управляют даныыми БД.

Прощай, MySQL, ты больше не СУБД.

Posted via ActualForum NNTP Server 1.4

6 сен 10, 20:07    [9393521]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
vadiminfo, я Вам рот конечно же не затыкаю, прошу по делу что-нибудь сказать. Заканчивайте, в смысле бла-бла. Раз про фамилии Вы чуть раньше так и не ответили, то скажите мнение применительно к такому примеру: когда говорят, что Оракл держит 100тыс клиентов, то серой мышкой в норке сидит Tuxedo. Следуя Вашей логике, нельзя сказать, что оракл справляется с таким числом клиентов?
6 сен 10, 20:09    [9393528]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
iscrafm
vadiminfo, я Вам рот конечно же не затыкаю, прошу по делу что-нибудь сказать. Заканчивайте, в смысле бла-бла. Раз про фамилии Вы чуть раньше так и не ответили, то скажите мнение применительно к такому примеру: когда говорят, что Оракл держит 100тыс клиентов, то серой мышкой в норке сидит Tuxedo. Следуя Вашей логике, нельзя сказать, что оракл справляется с таким числом клиентов?

Вы по делу говорите? По какому? Вам можно не заканчивать бла-бла, а мне нет? Чем Вы луче?
Ну Вы тоже тада заканчивайте Ваши назидания. Я не любитель назидательного чтения.
Про фамилии Вы кстати не ответили? Впрочем, мне все равно. Сомневаюсь что там есть что-то полезное для меня. Кто там внутри оракла сидит? Мож еще кто внутри телевизора?
6 сен 10, 21:29    [9393831]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Dimitry Sibiryakov

Прощай, MySQL, ты больше не СУБД.

Забейте. У Вас вырисовывается новая СУБД на основе FB. Счас пишут три: InterBase, Firebird, Yaffil
Но готовьте место для четвертой: распределенной.
6 сен 10, 21:41    [9393861]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
vadiminfo

Про фамилии Вы кстати не ответили? Впрочем, мне все равно. Сомневаюсь что там есть что-то полезное для меня. Кто там внутри оракла сидит? Мож еще кто внутри телевизора?

естественно не ответил, потому что Вопрос был Вам. (на всякий случай напоминаю) К чему паясничать?
6 сен 10, 22:00    [9393918]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
vadiminfo
новая СУБД на основе FB. Счас пишут три: InterBase, Firebird, Yaffil

особенно InterBase на основе FB.
6 сен 10, 22:04    [9393927]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
iscrafm
естественно не ответил, потому что Вопрос был Вам. (на всякий случай напоминаю) К чему паясничать?

Т.е. чисто Вы не знали и хотели узнать? Ну уж извените, в такой формулеровке не допер. Да и тада не понял зачем он в этой ветке: в раздел Орракла бы зашли. А если все же не просто хотели узнать, а поназидать, показать себя знатоком выдающимся, то Вы как бы после этого должны были дать "правильный" ответ. Может произвели бы на этот раз хорошее впечатление. Кто знает?
6 сен 10, 22:30    [9394011]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
vadiminfo, да, хотелось узнать, почему один стек технологий Вы считаете единым целым, а другой - к этой категории не относите.
6 сен 10, 22:40    [9394049]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
vadiminfo
artemana
По определению, система - это что то, состоящие из нескольких элементов, простых или сложных. Система, любая система, не обязательно состоит только из элементов произведенных одной командой или компанией.

Вы решили зайти с другой стороны?

Я всегда был именно на этой стороне, просто Вы никак не можете изменить на немного угол своего зрения. Почему и зачем так закостенели?
vadiminfo

Ну есть например, ИС - информационная система. Туда входит и СУБД, и Клиенты.
Произведенные разными. Ну туда моно навалить разных прослоек для кучи. Это наверное, будет все еще ИС - система, но СУБД то может остаться все та же Птица. Остальные не управляют даныыми БД.

Вот тут Вы на ровном месте ошибаетесь.
Поймите, что MDT как раз и управляет данными вместе с FireBird. И ничем, кроме управления реляционными абстрактными для нее данными, не занимается. И поэтому она вместе с Firebird представляет собой систему управления распределенными данными.
vadiminfo

Если Вам нуно назвать свое детище распределенной СУБД, то разве значит у Вас есть это самое СУБД. Как же его имя? Не ужели имя сей СУБД "Тендем МТД + Птица"?

А это наверно Вы изобрели 14 правило Дейта, система управления распределенными данными должна обладать именем?
vadiminfo


artemana

Так как по Вашему выходит, что если Firebird не принадлежит нам, а MDT не принадлежит владельца Firebird (IT-сообществу), то работоспособный комплекс из этих двух элементов, нельзя назвать системой управление распределенными данными. Это, наверно, 13 правило Дейта?

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

То что, они связанны именно с именем Дейта не знал, или подзабыл.
Но, во-первых, Вы не просили таких объяснений, во-вторых с данными правилами я знаком и привел трактовку ГЛАВНОГО правила (правила 0) на первой странице.
vadiminfo

Если можно назвать этот работоспособный комплекс распределенной СУБД, то называйте. Имя иму давайте. Я ж Вам предлагал. Вам даже понравилось, но Вы не назвали.

Вы все время отходите от необходимости анализа соответствия системы Firebird+MDT именно первому критерию Дейта и другим правилам. То Вам одного производителя подавай, то одно название. Откуда Вы эти требования берете не совсем ясно, но, ИМХО, в лучшем случае из пальца.

Используйте общепризнаные критерии и по ним оценивайте, как и обещали. А то, сами к четвертой странице разговора привели главный критерий, а после того, как я Вам указал на соответствие ему, начали опять танцы с бубном вокруг одного владельца и общего название. Айяяяй, как не красиво.
7 сен 10, 10:06    [9395152]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
artemana
Я всегда был именно на этой стороне, просто Вы никак не можете изменить на немного угол своего зрения. Почему и зачем так закостенели?

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

artemana

Вот тут Вы на ровном месте ошибаетесь.
Поймите, что MDT как раз и управляет данными вместе с FireBird. И ничем, кроме управления реляционными абстрактными для нее данными, не занимается. И поэтому она вместе с Firebird представляет собой систему управления распределенными данными.

Предпочту до выявления новых обстоятельств продолжать ошибаться тут на ровном месте. Фраза "реляционными абстрактными для нее данными" поизвела впечатление некоей новизны.
А Птица управляет тока реляционными не абстрактными для MDT или еще каким-то данными БД?


artemana

А это наверно Вы изобрели 14 правило Дейта, система управления распределенными данными должна обладать именем?

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


artemana

То что, они связанны именно с именем Дейта не знал, или подзабыл.
Но, во-первых, Вы не просили таких объяснений, во-вторых с данными правилами я знаком и привел трактовку ГЛАВНОГО правила (правила 0) на первой странице.

Так Вы их нашли наконец-то? Видите ли, могут подумать, что Вы сначала построили распределенную СУБД, а потом решили узнать что-нить про такие СУБД. И это может сбить с толку особенно закостенелых потребителей таких СУБД.

Я и сачс не прошу таких объяснений. Вы меня типа подловили, что я перепутал Дейта с Коддом. Понаделали выводов про меня как препод уличивший незадачливого студента? Называли правила мифическими? А теперь типа я не просил об этом? Ловко.

На Ваши трактовки правил Дейта я пока не смотрел, но учтите что есть трактовки продвинутых спецов. Они то разбираются в материале: не то что мы с Вами. Так что луче прочтите их траковки, а то найдут разницу и опять буит: Вас не просили об этом.

artemana

Вы все время отходите от необходимости анализа соответствия системы Firebird+MDT именно первому критерию Дейта и другим правилам. То Вам одного производителя подавай, то одно название. Откуда Вы эти требования берете не совсем ясно, но, ИМХО, в лучшем случае из пальца.

Я не то что отхожу от "необходимости анализа соответствия системы Firebird+MDT именно первому критерию Дейта и другим правилам", я к нему и не собирался подходить, до выяснения шо же такое MDT в клиент серверной архитектуре ИС. Сначало речь шла, что оно типа на клиенте данные закачивает, и автоматически там запросы выполняет. Теперь она именно на сервере БД вместе с Птицей данными ("реляционными абстрактными для нее") управляет. Но СУБД название не имеет. Может Типа MDT опция Firebird, а может наоборот. Кто знает?

artemana

Используйте общепризнаные критерии и по ним оценивайте, как и обещали. А то, сами к четвертой странице разговора привели главный критерий, а после того, как я Вам указал на соответствие ему, начали опять танцы с бубном вокруг одного владельца и общего название. Айяяяй, как не красиво.

Вы прям вошли во вкус учения меня.
Но я не приводил главного критерия для оценки распределенности MDT. Я приводил 0 правило Дейта Вам, чтобы Вы могли сравнить его 0 правилом Кодда и найти отличия. Потому что Вы настаивали, что я перпутал Дейта с Коддом и это мол правила Кодда.
Такой трюк подмены цели цитирования этого правила мною, по Вашему, красотища?
Впрочем, о вкусах не спорят.
7 сен 10, 22:26    [9400768]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
vadiminfo, учитывая то, что в последнем Вашем длинном посте Вы коснулись всего чего угодно, кроме технических характеристик и критериев их оценки, я не знаю что Вам отвечать.
9 сен 10, 10:46    [9409095]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
Sniff-Kadabra
Member

Откуда:
Сообщений: 20
автор не пропал, автора угнали в магадан)) зато сколько всего интересного сразу)

заранее извиняюсь, если понапишу глупостей или сто раз придуманных вещей)
artemana , если я правильно понял, у вас - половина, задуманного мною.
у вас, опять, поправьте, если не прав, все данные рассылаются по локальным машинам.
я предлагаю разделять данные по некоторым признакам и использовать совместную конфигурацию.
собственно, я пишу СУБД на основе postgresql и sqlite.
postgresql - обычный клиент-сервер, хранит медленноменяющиеся, большие данные, которые приложения запрашивают разово(по возможности), при старте, например.
sqlite - движок "динамической" части, инфа хранится везде, реплицируется с сервера на локальные машины (на каждой машине запущена служба, собственно, поддерживающая целостность бд)
плюсы - возможность выгрузить часть данных в клиент-серверную систему. так, например, если "статическая" часть - сотни мегобайт, то при подключении нового рабочего места реплицировать всю базу очень накладно, динамическая должна быть легче на подъём.
минусы - есессно, сложность в реализации транзакций, должны быть какие-никакие, но двухфазные фиксации, я также планировал по возможности минимизировать число связей из статики в динамику (ссылки из динамики в статику сильно не вредят)
ну, и, собственно, если подходить по науке, то разделение данных - вопрос также открытый, "некоторые признаки", по которым разделяются данные - частота обращений, объемы пересылаемой информации, связность данных, скорость изменения и время жизни объектов (строк). имхо, стоит обсудить)
10 сен 10, 11:28    [9416643]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
Sniff-Kadabra
автор не пропал, автора угнали в магадан)) зато сколько всего интересного сразу)

заранее извиняюсь, если понапишу глупостей или сто раз придуманных вещей)
artemana , если я правильно понял, у вас - половина, задуманного мною.
у вас, опять, поправьте, если не прав, все данные рассылаются по локальным машинам.

Нет, не все.

P.S.
Этот раздел планов уже реализован, увы описание отстает.
10 сен 10, 11:47    [9416899]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
Sniff-Kadabra
Member

Откуда:
Сообщений: 20
ага..artemana слушайте, оказывается мы правда сходными вещами занимаемся.
а на каких основаниях у вас проводятся отсечения? вы как-то формализовывали критерии?
у меня была идея подойти к вопросу очень научно, сформировать критерии, построить целевую ф-цию и провести её оптимизацию, получив, соответствено, реальные критерии разделения данных
(т.е., информация может меняться раз в 5 секунд, раз в час, раз в два, три, итд, весьма непрерывно, и как лучше её разделять - вопрос открытый)
10 сен 10, 12:24    [9417307]     Ответить | Цитировать Сообщить модератору
 Re: СУБД: клиент-серверные и/или распределенные  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
Sniff-Kadabra
ага..artemana слушайте, оказывается мы правда сходными вещами занимаемся.
а на каких основаниях у вас проводятся отсечения? вы как-то формализовывали критерии?
у меня была идея подойти к вопросу очень научно, сформировать критерии, построить целевую ф-цию и провести её оптимизацию, получив, соответствено, реальные критерии разделения данных
(т.е., информация может меняться раз в 5 секунд, раз в час, раз в два, три, итд, весьма непрерывно, и как лучше её разделять - вопрос открытый)

Для меня почти полностью.
У нас только средства усечение. Общую методику оценки их применимости мы не разрабатывали, в своих проектах в основном отсекаем только исходя из целей безопасности. Отсечение для повышения производительности практически не используем, так как при распределение данных по клиентам проблемы с скоростью работы и так нет.
10 сен 10, 12:34    [9417455]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить