Зависит от огромности объема - в цифрах. Я слышал отзывы достаточно уважаемых мной людей, что 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Извините, но тут возникает один вопросик - она у Вас есть или у Оракла ? Это разные однако понятия.
Безусловно, разные. Но разные - в основном в понятиях "насколько хорошо реализовано" и "сколько стоит".

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