Зависит от огромности объема - в цифрах. Я слышал отзывы достаточно уважаемых мной людей, что Interbase плохо работает с большими базами.

Для больших я бы посоветовал Oracle :) Для _очень_ больших - не знаю, наверное Terradata :)

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

Все же базу нужно выбирать под требования с учетом будущего развития - и никак иначе. "Не умеем" - фактор, ответом на который будет "научитесь" или "найдите того, кто умеет".

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

Lora__kТаблиц м.б. не очень много (точно пока сказать трудно), а вот записей в таблице - порядка 100000. Файлы результатов весят примерно 2Гб.
Пожалуй, стоит еще уточнить - за какой период времени столько набирается.

По сказанному - создается впечатление, что для Interbase задача несколько великовата, по крайней мере если не уметь его использовать на 100%, а более мощные должны потянуть без проблем.

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

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

Во-вторых, практическая возможность универсально писать на SQL-92 последний раз обсуждалась здесь несколько дней назад.

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

ShultzeКстати, нормальный подход, я прежде чем пересесть на хонду с коробкой автомат и 180лс на москвиче откатался год.
Для машин - нормальный. Именно что рассчитывая отделаться от нее через год.

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

ShultzeЯ выбрал бы "золотую середину" - MS SQL, но, повторюсь, хотелось бы услышать примерный объем данных и количество пользователей,
Хм. Имхо людям стоит найти знакомого консультанта и выбрать то, что этот консультант знает :)

Shultze и что немаловажно - финансовые основы проекта, будет ли разработка, например под Oracle, целесообразна в денежном плане.
Хм. Есть некая легенда - про дорогой Оракл. На самом деле Оракл - как и любой другой продукт - может оказаться дорогим в той или иной ситуации.

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

Lora__kно надо сказать, что периодически (скажем раз в полгода) из архива будут удалятся "старые" и "не используемые" измерения,
Хм. Уверены ли Вы, что эти цифры действительно становятся бесполезными с такой скоростью? Или это то, на что Вы предполагаете пойти в целях удержания объема?

В большинстве известных мне систем данные по большому счету не удаляются вообще. Их можно отложить - в том же Оракле вывести в read-only tablespace, а потом - вывести в оффлайн, записать на CD и положить CD в сейф - но обычно хотят хранить все. В этом суть БД :)

Lora__kт.е. цифры я привела максимальные. И еще есть предложение разбить весь архив на части(по каким-либо параметрам).
Опять-таки: если это объективно разумно - нужно ли вообще собирать эти записи в центре?

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

Учтите, что в ходе разработки и эксплуатации системы, особенно внутренней, аппетиты растут довольно резко. То есть если человеку еще не приходила в голову мысль получить такой-то отчет - скорее всего, она придет.

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

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

P.S. Я тут сегодня выслушал отчет о работе смежников - они закачали данные из текстовых файлов в Access, потом из Access перекинули в MS SQL, а уж из MS SQL смогли передать в Oracle. Воистину, если людям нечем заняться......

ASCRUSИзвините, но тут возникает один вопросик - она у Вас есть или у Оракла ? Это разные однако понятия.
Безусловно, разные. Но разные - в основном в понятиях "насколько хорошо реализовано" и "сколько стоит".

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

Рыжий КотЭто фраза гипотетическая или реклама своей разработки? :)
Я, кажется, сказал "есть". Если угодно, считайте рекламой - хотя я в данном случае не имел этого в виду.

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

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

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

P.S. На всякий случай уточню, что под "Есть вопросы" я не имею в виду "есть проблемы" - я имею в виду "не знаем, как делать".

arniУважаемые Softwarer и ASCRUS действительно полагают, что 100 тыс. записей на таблицу, а хоть бы и миллион, а хоть бы этих таблиц и с полсотни - это сложная задача для IB/FB?
Я знаю как факт утверждение человека, в компетентности которого уверен: для баз больше полугига лучше выбирать что-то помощнее интербейза. Разумеется, как любое общее утверждение, оно применимо с оговорками, однако в данном случае (нулевой стартовый уровень) игнорировать его было бы неразумно.

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

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

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

Понятно, что с тупым хранением справится любая БД. Однако баз, суть которых в тупом хранении, я видел очень мало. Зато явно указаны как минимум зачатки аналитики - а из зачатков регулярно вырастают вполне серьезные требования. Аппетиты заказчиков растут много быстрее умений разработчиков.

Давайте тогда уж и я отвечу.

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

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

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

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

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

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

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

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

В серверную часть входят несколько подпрограмм контроля данных и профилактики; они также пишут письма администратору при обнаружении проблем.

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

Рыжий КотASA использует для всех этих целей transaction log, в базу ничего лишнего не пишется.
Я обдумываю этот вариант, но пока не готов его реализовать. "Извне" трудно делать такие решения ;)

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

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

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

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

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

Рыжий КотASA использует для всех этих целей transaction log, в базу ничего лишнего не пишется.
Я обдумываю этот вариант, но пока не готов его реализовать. "Извне" трудно делать такие решения ;)

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

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

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

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

AAron2vadiminfo
Интересно, а если в результате репликации данные должны претерпеть некую трансформацию? Тогда как? Если схемы данных на издателе и подписчике не совпадают?
Можно сделать, например, так, как у меня. Это не повод в любом случае генерить уйму дополнительного в общем случае тривиального кода.