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

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
softwarer
ASCRUS
Если репликации по плохим каналам и через оффлайн не нужны и проблем с передачей данных и администрированием удаленных СУБД не будет, то полностью присоединяюсь к мнению.


Хм. Ну вот у меня есть репликация для Оракла по плохим каналам :)

Имхо, грамотный консультант - важнее. Даже если он посоветует репликацию на дискетках.



Это фраза гипотетическая или реклама своей разработки? :)

У мена коллега из Франции тоже сам написал репликацию под Оракл.
Он потратил больше года на отладку и вылавливание багов.
Но тем не менее, я уверен, что его репликация будет уступать ASA.
наверное это все от того, что рядом не было грамотного консультанта :).
23 ноя 04, 14:03    [1128891]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67393
Блог
Рыжий Кот
Это фраза гипотетическая или реклама своей разработки? :)

Я, кажется, сказал "есть". Если угодно, считайте рекламой - хотя я в данном случае не имел этого в виду.

Рыжий Кот
Он потратил больше года на отладку и вылавливание багов.

Это странно. Развитие - согласен, а вот персонально на отладку - многовато. Хотя, безусловно, это вопрос того, что он туда заложил.

Рыжий Кот
Но тем не менее, я уверен, что его репликация будет уступать ASA.

Вполне возможно. Никто не предлагает меряться репликациями - скажем, для поставленной задачи моей разработки хватит процентов на 500. И если возможностей ASA хватит на 1500% - так ли это важно?

Грубо говоря, из варианта "нет вопросов с репликацией, есть вопросы со всем остальным" и "нет вопросов ни с чем, кроме репликации" я бы на месте автора темы выбрал второй.

P.S. На всякий случай уточню, что под "Есть вопросы" я не имею в виду "есть проблемы" - я имею в виду "не знаем, как делать".
23 ноя 04, 14:12    [1128942]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
Yo!
Guest
Lora__k
[
В основном, центральная база будет обрабатывать различные запросы на контроль отдельных групп измерений, обрабатывать результаты и генерировать отчеты.


имхо более правильно организовать нотификации если какие-то группы выбиваются из заданых параметров. раз центральный сервер один то можно рассматривать что-то серьозное. interbase и клоны как DW себя не позиционируют да и нету там ничего для твоих нужд, я бы рассматривал oracle, mssql, syabse IQ, posgres (db2 не видел т.к. их очень у нас мало и не вкурсе скока стоит).
oracle и mssql по лицензиям стоят одинаково - потянут ~$5K, скока sybase стоит тут человек просветит ;) posgres бесплатен, но и фишек у него ...
23 ноя 04, 14:32    [1129077]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
Zaxx
Guest
Shultze
не смотрите в сторону Oracle, безумная стоимость приобретения/внедрения/владения


Не надо вводить людей в заблуждение красивыми фразами "безумная стоимость приобретения/внедрения/владения". Сходите на http://store.oracle.com перед тем как писать про "безумную стоимость". В зависомости от Edition-а оракл стоит от $149/user -Standart Edition One (или $300/user - Standart Edition), что не безумнее чем стоимость предложенной вами "золотой середины" - MS SQL ($1500 за 5 лицензий).
24 ноя 04, 08:47    [1130940]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
arni
Member

Откуда: Иваново
Сообщений: 3544
Уважаемые Softwarer и ASCRUS действительно полагают, что 100 тыс. записей на таблицу, а хоть бы и миллион, а хоть бы этих таблиц и с полсотни - это сложная задача для IB/FB?

Удажаемые действительно делают свои выводы на основании кол-ва записей и суммарного объема данных?

Конечно, постановки задачи здесь и близко не стояло.
Конечно, не понятно какого рода запросы какой "этажности" планируются.
Конечно, не ясно будут ли и сколько использованы SP, View и т.д., и какой сложности.

Когда я встречаю при описании сложности задачи "n таблиц в сумме составляющих m Mb/Gb" я могу с уверенностью прикинуть лишь одно: время полного фетча составит столько-то. Причем эти цифры будут в основном коррелировать с толщиной каналов связи и средним временем доступа винта.

Несложные селекты с подключением пары-тройки справочных таблиц будут исполнены на любой серьезной СУБД с непринципиальной разницей в скорости (при прочих равных условиях: индексы, структура данных и т.д.).

Причем на эффективность/производительность в таких условиях куда большее влияние окажут знание/опыт разработчика и хар-ки железа, чем выбор конкретной СУБД. ИМХО, конечно.

Где признаки того, что решение задачи выйдет за эти элеменарные требования? С нулем-то опытом разработчиков?

Настораживает фраза "скорее агрегация" - но если все упрется в group by по 2-3 полям - не смешите меня.
Второй щекотливый момент - распределенность и процедуры синхронизации/репликации. Однако, как уже было замечено, автор топика похоже понимает под этим лишь тупой сброс региональных данных в БД централизованную - ноу проблем хоть на FoxPro.

Мой вывод: исходя из озвученных исходных данных, Вам подойдет ЛЮБАЯ серьезная СУБД. Хотите сузить круг поиска - не стесняйтесь расказать о специфике предметной области, конкретизируйте виды обработки данных. Короче, больше информации.
24 ноя 04, 10:13    [1131172]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
Yo!
Guest
автор
Причем на эффективность/производительность в таких условиях куда большее влияние окажут знание/опыт разработчика и хар-ки железа, чем выбор конкретной СУБД. ИМХО, конечно.


вы серьозно считаете что ваши знания смогут заменить partioning, materialized view, index organized tables и т.п. :) ?
24 ноя 04, 10:23    [1131206]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
Guest_2
Guest
автор
вы серьозно считаете что ваши знания смогут заменить partioning, materialized view, index organized tables и т.п. :) ?

В каких-то задачах - да, в каких-то - нет. ;-)
24 ноя 04, 10:27    [1131221]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
arni
Member

Откуда: Иваново
Сообщений: 3544
Yo!
автор
Причем на эффективность/производительность в таких условиях куда большее влияние окажут знание/опыт разработчика и хар-ки железа, чем выбор конкретной СУБД. ИМХО, конечно.


вы серьозно считаете что ваши знания смогут заменить partioning, materialized view, index organized tables и т.п. :) ?


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

P.S. Вспоминаю первый год после института: сразу на Oracle, опыта нет. Курс молодого бойца без отрыва от производства - читай в промышленной системе.
Сильно гордился, что что-то там наворотил через временные таблицы, благо сервер стерпел.
Сейчас оглядываюсь - нах нуж было? Знание базового SQL позволило бы решить все хотелки быстрее/красивее/эфективней.

Имхо, модные штучки, вроде перечисленных Вами, способствуют развращению неопытных мозгов. Упоминать/рекомендовать их при выборе СУБД для команды безусых - вред один.
24 ноя 04, 11:15    [1131439]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
По вопросу:
В общем, согласитесь, что БД никак не IB получается - MS SQL, Oracle, Sybase, любая из них, какая приглянется разработчику. Учитывая то, что это разные города, техника неизвестно какая... Тут MS SQL или Sybase будет лучше (проще, легче и т.д.). ИМХО :)

По принципу:
автор
Кстати, нормальный подход, я прежде чем пересесть на хонду с коробкой автомат и 180лс на москвиче откатался год.

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

По репликации:
Ну у нас есть свой механизм репликации. Любые каналы - все пофиг. Работает под MS SQL, можно под любой сервер. Репликация происходит через ХП - поэтому полный контроль и широкий простор. Никаких проблем вот уже 3 года. Нахрен не нужна родная замороченная репликация.

-- Tygra's --
24 ноя 04, 11:18    [1131454]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
EvgErmak
Member

Откуда:
Сообщений: 650
Удобство экплуатации FB:
у нас FB работает на одной двухпроцевой машине с 1С с DBF'ами на MetaFrame. 5 эксплуатируемых баз ~ 40 useroв. За 2.5 года эксплуатации не свалилась ни одна БД при постоянных сбоях в локалке из за отключениях в питании. При установке программы Useraм подбрасывается несколько Dll'ок (gds32,FBCLIENT) и все. Рабочее время тратится на логику БД, а не на борьбу с сервером.
(У друга 1с вертится на MS SQL, сервак периодично валится на обрыве локалки) Важна логика проекирования БД и удобство-стабильность работы SQL-сервера.
24 ноя 04, 11:26    [1131498]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
Yo!
Guest
автор
Имхо, модные штучки, вроде перечисленных Вами, способствуют развращению неопытных мозгов. Упоминать/рекомендовать их при выборе СУБД для команды безусых - вред один.


а можно конкретней что из перечисленого может так губительно повлиять на неокрепшие умы ? :)
это стандартный набор для пускания агрегированых отчетов ... их изучение займет 2 дня и будет гораздо полезней чем изучение уникальных способностей клонов интербэйза, в которые даже я так и не вьехал. дэвушка может не сразу а через какое-то время все равно дойдет до понимания что архивные данные нельзя удалять - они будут важны для последующего анализа, а это значит бд будет расти и требование вместе с пониманием ...
24 ноя 04, 11:31    [1131532]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Рабочее время тратится на логику БД, а не на борьбу с сервером.

Дык все так делают

автор
(У друга 1с вертится на MS SQL, сервак периодично валится на обрыве локалки)

Это проблема рук вашего друга и 1С. И что значит валится? Куда? Каким образом? Руки другу выгнуть в другую сторону, 1С выкинуть... Много есть способов :)
автор
Важна логика проекирования БД и удобство-стабильность работы SQL-сервера.

Вот-вот. Для всех СУБД :) Логика правда к СУБД не относится - это скорее к голове разработчика :)

-- Tygra's --
24 ноя 04, 11:32    [1131535]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
>вы серьозно считаете что ваши знания смогут заменить partioning, materialized view,
>index organized tables и т.п. :) ?
А Вы серъезно считаете, что вышеперечисленные заклинания заменят знания? :-)

Posted via ActualForum NNTP Server 1.1

24 ноя 04, 12:00    [1131649]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
Yo!
Guest
автор
А Вы серъезно считаете, что вышеперечисленные заклинания заменят знания? :-)


нет, я считаю что потратить 2 дня на изучение стандартных заклинаний дешевле, чем тратить месяца на изобретение очередных велосипедов.
24 ноя 04, 12:20    [1131748]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
Lora__k

Таблиц м.б. не очень много (точно пока сказать трудно), а вот записей в таблице - порядка 100000. Файлы результатов весят примерно 2Гб.
У меня в рабочей базе ~30таблиц, из которых две- по 2 млн. записей. В одной из них ~30 полей, в другой ~10. Общий размер базы < 1 GB.
СУБД- Firebird.


ps
на вопрос:
imho, Firebird - хорошо.
24 ноя 04, 12:43    [1131846]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67393
Блог
arni
Уважаемые Softwarer и ASCRUS действительно полагают, что 100 тыс. записей на таблицу, а хоть бы и миллион, а хоть бы этих таблиц и с полсотни - это сложная задача для IB/FB?

Я знаю как факт утверждение человека, в компетентности которого уверен: для баз больше полугига лучше выбирать что-то помощнее интербейза. Разумеется, как любое общее утверждение, оно применимо с оговорками, однако в данном случае (нулевой стартовый уровень) игнорировать его было бы неразумно.

arni
Когда я встречаю при описании сложности задачи "n таблиц в сумме составляющих m Mb/Gb" я могу с уверенностью прикинуть лишь одно: время полного фетча

Несложные селекты с подключением пары-тройки справочных таблиц

Где признаки того, что решение задачи выйдет за эти элеменарные требования? С нулем-то опытом разработчиков?

Я бы спросил - где признаки того, что не выйдет?

Понятно, что с тупым хранением справится любая БД. Однако баз, суть которых в тупом хранении, я видел очень мало. Зато явно указаны как минимум зачатки аналитики - а из зачатков регулярно вырастают вполне серьезные требования. Аппетиты заказчиков растут много быстрее умений разработчиков.
24 ноя 04, 14:05    [1132295]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
tygra

...
По репликации:
Ну у нас есть свой механизм репликации. Любые каналы - все пофиг. Работает под MS SQL, можно под любой сервер. Репликация происходит через ХП - поэтому полный контроль и широкий простор. Никаких проблем вот уже 3 года. Нахрен не нужна родная замороченная репликация.

-- Tygra's --


Нужно было приписать "нахрен НАМ не нужна..."
У вас репликация между 2 машинами? или между 10? а каждая вторая из этих 10 несет еще постолько же подчиненных узлов?
Если не трудно, опишите свой механизм, как передается, какие средства проверки, какое участие в этом оператора, тем более, что фраза
"можно под любой сервер", более чем привлекательна.
24 ноя 04, 14:12    [1132334]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
Yo!
Guest
https://www.sql.ru/forum/actualthread.aspx?tid=140707

о ! совсем новенький велосипед :)
24 ноя 04, 14:22    [1132373]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
2 Рыжий Кот

Под любой сервер - это значит под тот, к которому можно приконнектиться из Дельфей :). Ну для простоты и чтобы ничего не менять - через MDAC.

Действительно, нахрен НАМ не нужна :))

А механизм репликации простой, но хитрый :), возможно он и необычный, но зато работает. Правда мы как-то его называем не репликация, а "обмен" - и слово короче, и русское оно :).
Секрет это, не выдам я его
Значит так:
Гуидов нет никаких. На ID (numeric) основывается - подразумевается, что в каждой таблице есть такое поле. У нас есть - и хорошо. Но и под гуид можно, если кому нужно.
Есть таблица репликации, где лежат ID того, чего нужно реплицировать, и тип репликации. Ну дата там, результат операции.
Есть робот, который ходит раз в N минут в эту таблицу и реплицирует то, чего там есть.
Есть тип репликации. Вот он за все и отвечает. На нем: сервер, откуда брать данные, сервер, куда гнать данные.
И - самое главное - как оно работает:
На типе репликации есть имя ХП, которая отдает данные. Хоть в нескольких рекордсетах. Так же на типе есть список принимаемых ХП, на каждый отдаваемый рекордсет своя. Робот по каждой записи таблицы репликации дергает ХП с входным параметром ID, которая отдает данные, дальше на каждую строку каждого рекордсета соответственно дергает ХП принимающие принимающего сервера БД, заполняя все параметры. которые есть в принимающей ХП из данных записи рекордсета отдающей ХП. Если параметров больше, чем полей в данных - пишется ошибка. И так далее, пока есть чего работать. Да, можно указать, чтобы вся обработка одной записи репликации заключена была в транзакцию.
В таблицу репликации данные попадают так: в той ХП (у нас вся система на ХП, поэтому проблем нет), которая обрабатывает то. чего должно попасть в репликацию, дергается ХП добавления репликации с ID объекта и типом репликации. Можно конечно и поле последнего изменения хранить, но нам именно так проще - не всегда нужно отдавать на обмен.
Пример ХП:
на отдачу
create procedure xxx 
 @ID int
as begin
select ID, Name, Address 
from Client 
where ID = @ID
end
на прием
create procedure xxx_in
 @ID int,
 @Name varchar(100),
 @Address varchar(100)
as begin
 if not exists(select 1 from Client where ID = @ID)
  insert into Client .....
 else
 update Client
 ...
 where ID = @ID

--и еще чего-то можно тут делать
end

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


Ну вот вроде и все. Если чего я непонятно написал - отвечу. Работает вот уже сколько - нет проблем.

-- Tygra's --
24 ноя 04, 15:09    [1132584]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67393
Блог
Давайте тогда уж и я отвечу.

Рыжий Кот
У вас репликация между 2 машинами? или между 10? а каждая вторая из этих 10 несет еще постолько же подчиненных узлов?

В принципе - произвольный граф. Связный, разумеется ;) Но желательна "снежинка", поскольку иначе здорово повышается вероятность коллизий. Простой пример проблем при наличии альтернативных путей - если на сервере A создана запись, на сервере B она изменена - в силу каких-то причин это изменение может приехать на сервер C раньше, чем (другим путем) туда приедет оригинальная запись с A.

Рыжий Кот
Если не трудно, опишите свой механизм, как передается, какие средства проверки, какое участие в этом оператора

Участия человека - практически никакого. Реально уже почти год эксплуатируется без квалифицированного присмотра.

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

Транспортная программа передает эти пакеты транспортной программе, работающей с другими серверами. Данные упаковываются и передаются по ftp (предусмотрено легкое подключение чего угодно). На другой стороне данные принимаются и кладутся на сервер. Серверный код выполняет изменения и при необходимости передает их дальше (своим линкам).

Все обвешано возможностью подключать дополнительный код - типа "обработчиков событий". В частности, есть возможность реализовать что-то типа instead of; то есть вместо собственно инсерта пришедших данных выполняется заданный код с этими данными. Код в принципе произвольный; так, реализована куча механизмов типа "отклика", например, пинговалка, которая используется для проверки живости всего процесса.

Ошибки - то, что регистрируется при попытке выполнить изменения. Есть возможность подвесить собственный код обработки ошибок, но в принципе они складываются на ручную обработку. Есть некоторые тонкости - например, при ошибках, свидетельствующих о проходящем накатывании патчей, репликация автоматически останавливается и ждет, после чего повторяет операцию. По моему опыту, после того как репликация грамотно отстроена, ошибок практически не возникает даже с учетом постановки на репликацию новых таблиц.

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

Транспортные программы - сообщают об ошибках (я использую smtp).

В серверную часть входят несколько подпрограмм контроля данных и профилактики; они также пишут письма администратору при обнаружении проблем.
24 ноя 04, 16:15    [1132940]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
2 tygra, softwarer
очень интересные решения
правда вы храните в базе еще таблицу с изменениями,
по какому принципу опустошается она?
что кладется в
ASA использует для всех этих целей transaction log, в базу ничего лишнего не пишется.
Еще один вопрос:
нужно добавить во все базы, участвующие в реплике, новый код, или
поля или раздать права. что вы в этом случае делаете?


Картинка с другого сайта.
24 ноя 04, 19:28    [1133508]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
EvgErmak
Важна логика проекирования БД и удобство-стабильность работы SQL-сервера.


И отсутствие понятия "невосстановимый бэкап" как класса ;))
24 ноя 04, 20:41    [1133602]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67393
Блог
Рыжий Кот
правда вы храните в базе еще таблицу с изменениями,
по какому принципу опустошается она?

Хм. Не совсем уверен, что понял вопрос. Скажем так, после обработки данные "удаляются", хранятся какое-то время в "удаленном" виде (нужно в основном для администрирования - просмотр истории по записям, анализ статистики итп), после чего purge-атся по времени.

Рыжий Кот
ASA использует для всех этих целей transaction log, в базу ничего лишнего не пишется.

Я обдумываю этот вариант, но пока не готов его реализовать. "Извне" трудно делать такие решения ;)

Рыжий Кот
нужно добавить во все базы, участвующие в реплике, новый код, или поля или раздать права. что вы в этом случае делаете?

Да в общем-то ничего.

Специфика проекта, в рамках которого репликатор был реализован, не требовала репликации структурных изменений - любые патчи накатывались руками. Поэтому репликатор только поддерживает такой режим - останавливается на время DDL, чтобы не возникало ошибок/конфликтов/блокировок объектов.

Фактически происходит следующее - в нормальной ситуации скрипт изменений начинается с сигнала репликатору (блокировка на какое-то время). Если репликатор в этот момент активен - он попробует доработать, но в случае любой ошибки откатится и будет ждать. Если сигнала не было, но происходит ошибка, типичная для наката патчей (настраиваемый список) - репликатор сообщает об этом администратору и сам взводит блокировку на 15 минут.

Саму по себе репликацию DDL можно организовать существующими средствами - для этого делается табличка скриптов, а событие "после прихода" реализуется для выполнения пришедшего кода. Но тут встает вопрос обработки всевозможных ошибок - за отсутствием потребности я этим не занимался.
25 ноя 04, 11:40    [1134562]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67393
Блог
Рыжий Кот
правда вы храните в базе еще таблицу с изменениями,
по какому принципу опустошается она?

Хм. Не совсем уверен, что понял вопрос. Скажем так, после обработки данные "удаляются", хранятся какое-то время в "удаленном" виде (нужно в основном для администрирования - просмотр истории по записям, анализ статистики итп), после чего purge-атся по времени.

Рыжий Кот
ASA использует для всех этих целей transaction log, в базу ничего лишнего не пишется.

Я обдумываю этот вариант, но пока не готов его реализовать. "Извне" трудно делать такие решения ;)

Рыжий Кот
нужно добавить во все базы, участвующие в реплике, новый код, или поля или раздать права. что вы в этом случае делаете?

Да в общем-то ничего.

Специфика проекта, в рамках которого репликатор был реализован, не требовала репликации структурных изменений - любые патчи накатывались руками. Поэтому репликатор только поддерживает такой режим - останавливается на время DDL, чтобы не возникало ошибок/конфликтов/блокировок объектов.

Фактически происходит следующее - в нормальной ситуации скрипт изменений начинается с сигнала репликатору (блокировка на какое-то время). Если репликатор в этот момент активен - он попробует доработать, но в случае любой ошибки откатится и будет ждать. Если сигнала не было, но происходит ошибка, типичная для наката патчей (настраиваемый список) - репликатор сообщает об этом администратору и сам взводит блокировку на 15 минут.

Саму по себе репликацию DDL можно организовать существующими средствами - для этого делается табличка скриптов, а событие "после прихода" реализуется для выполнения пришедшего кода. Но тут встает вопрос обработки всевозможных ошибок - за отсутствием потребности я этим не занимался.
25 ноя 04, 11:41    [1134563]     Ответить | Цитировать Сообщить модератору
 Re: InterBase(FB) - хорошо или плохо?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
2 Рыжий Кот
автор
правда вы храните в базе еще таблицу с изменениями,
по какому принципу опустошается она?

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

Ну это не относится к репликации данных. Руками все делается - количество БД не такое, чтобы в лом было. Но если нужно будет - можно и ХП и права реплицировать. Проблем не будет.

-- Tygra's --
25 ноя 04, 12:16    [1134721]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить