Лучшая СУБД для научных проектов.

← →
GDI+ (2010-03-21 15:26) [0]

Продолжение спора с другого форума.

Требуется СУБД:
- бесплатная (или бесплатная для некоммерческого использования)
- оперирование от 1 до 100 Гб данных.
- малое число коннектов (хотя работа может идти в нескольких потоках).
- соответствие ACID(транзакции).
- возможность писать собственные встроенные процедуры (на встроенном языке), подключать высокопроизводительные библиотеки на С++ и иметь готовую библиотеку математических функций (для предварительных вычислений во время выборки данных).
- простота установки/администрирования (так как это будут делать неспециалисты) и надёжность к сбоям или автоматическое восстановление после сбоев.
- мультиплатформенности не нужно, но работоспособность на трёх основных ОС (Windows, MacOS, Linux) должна быть.
- бесплатные библиотеки коннекта к базе для С++, Python, Java.

Пока вижу для рекомендации только Firebird / PostgreSQL.

← →
Sergey Masloff (2010-03-21 15:34) [1]

Пока вижу только возможность дать совет: наймите профессионала

← →
sniknik © (2010-03-21 15:36) [2]

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

← →
Loginov Dmitry © (2010-03-21 15:37) [3]

FireBird IMHO удовлетворяет всем пунктам.

← →
GDI+ (2010-03-21 15:41) [4]

> sniknik © (21.03.10 15:36) [2]
>
> а я вот вижу необходимость в других постановщиках задачи.
> с адекватным подходом к хранению своей таблички со списком
> контактов...

Ну скажем это данные с метеодатчиков за несколько лет и разные регионов страны (не Россия).

← →
Имяозер (2010-03-21 22:21) [5]

MySQL.

← →
test © (2010-03-21 22:23) [6]

Смотря кто ее админить будет, лучше конечно PostgreSQL, но если админа нету то Firebird IMHO.

← →
Псалтырь © (2010-03-21 22:37) [7]

PostgreSQL.

← →
test © (2010-03-21 23:25) [8]

GDI+ (21.03.10 15:41) [4]
Как БД построишь еще, тут может и Оракл лежать не вставая, а может и MySQL весело крутиться.

← →
PEAKTOP © (2010-03-21 23:45) [9]

GDI+ (21.03.10 15:26)

Холиварим ? Ну, тогда я.
Пока вижу для рекомендации только Firebird / PostgreSQL.

А больше и не увидишь - реально работающие (в том числе из коробки) только две эти альтернативы.

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

Но а если совсем трудно будет - брось монетку. =)

← →
test © (2010-03-21 23:50) [10]

PEAKTOP © (21.03.10 23:45) [9]

Если монетка повиснет в воздухе?
Если монетка станет ребром?
Если монетка потеряется?
Если монетка сломается?
Если монетка воткнется в потолок?
))

← →
PEAKTOP © (2010-03-21 23:54) [11]

> Если монетка повиснет в воздухе?
> Если монетка станет ребром?
> Если монетка потеряется?
> Если монетка сломается?
> Если монетка воткнется в потолок?

Значит - перст судьбы.
И тогда появится второй топик "а что выбрать, кроме Слонопотама и Firebird ?"

=)

← →
Правильный$Вася (2010-03-21 23:55) [12]

> Если монетка воткнется в потолок?

надо бросать в пруд, с русалками

← →
test © (2010-03-22 00:03) [13]

Правильный$Вася (21.03.10 23:55) [12]
Ну тогда MySQL у них же вроде дельфин.

← →
tesseract © (2010-03-22 10:10) [14]

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

Ээээ, а чай приносить СУБД не должна ? Вычисления - задача не СУБД, а клиента.

← →
KSergey © (2010-03-22 10:41) [15]

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

← →
Думкин © (2010-03-22 10:47) [16]

> KSergey © (22.03.10 10:41) [15]
> мдя, в будущее оечественной метеорологии верится с трудом.
>

Читай внимательнее:

> разные регионов страны (не Россия).

я подозреваю, что это за страна такая, но писать не буду.

← →
Медвежонок Пятачок © (2010-03-22 10:49) [17]

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

либо mssql и хранимки на дотнете, либо оракол и ява код там где pl/sql недостаточно

← →
b z (2010-03-22 11:05) [18]

> либо оракол и ява код там где pl/sql недостаточно
Тут тоже можно "хранимки на дотнете".

← →
GDI+ (2010-03-22 11:35) [19]

> Медвежонок Пятачок © (22.03.10 10:49) [17]
>
> готовую библиотеку математических функций (для предварительных
> > вычислений во время выборки данных).
>
> либо mssql и хранимки на дотнете, либо оракол и ява код
> там где pl/sql недостаточно

Вы бы доверили базу Oracle администрировать студенту, если интересует результат?
Ну а в PostgreSql хранимки можно писать хоть на питоне, оно всеядное.

← →
GDI+ (2010-03-22 11:38) [20]

В общем к базе Oracle еще нужно домовёнка ставить за 1500$, с MSSql там чуть получше, но тоже надёжность не их конёк.

← →
Медвежонок Пятачок © (2010-03-22 11:44) [21]

а откуда такая озабоченность надежностью при озвученных условиях?

коннектов мало.
но зачем-то требуется доступ из явы питона и о боже, с++

← →
Медвежонок Пятачок © (2010-03-22 11:49) [22]

возьмите mssql.
напишите клиента на делфи/vs.
для всего остального зоопарка добавьте iis и опубликуйте необходимые веб-сервисы.

и все!

← →
GDI+ (2010-03-22 12:14) [23]

> Медвежонок Пятачок © (22.03.10 11:49) [22]
>
> возьмите mssql.

А там есть бесплатная версия для базы более 4Гб? Не то чтобы я против использования пиратки, но как-то не комфортно если можно избежать.

← →
GDI+ (2010-03-22 12:16) [24]

> Медвежонок Пятачок © (22.03.10 11:44) [21]
>
> коннектов мало.
> но зачем-то требуется доступ из явы питона и о боже, с++

Покажите на Delphi библиотеку работы с длинными числами (не уверен но теоретически может возникнуть необходимость). А на Яве и Питоне есть.

← →
Медвежонок Пятачок © (2010-03-22 12:21) [25]

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

кроме того четырехгиговых, баз может быть не одна, а двадцать одна ....

← →
GDI+ (2010-03-22 12:31) [26]

> Медвежонок Пятачок © (22.03.10 12:21) [25]
>
> если речь про экспресс эдишен, то ограничение в 4 гига -
> оно как бы не совсем ограничение. экспресс умеет работать
> с файлами превышающими 4 гига. он всего лишь не умеет автоматом
> увеличивать размер базы больше 4 гигов. но базу ведь можно
> изначально создать размером каким хочется.
> не обязательно в экспресс.
>
> кроме того четырехгиговых, баз может быть не одна, а двадцать
> одна ....

И с учетом всего вышесказанного в сторону MSSQL проще воспользоваться пираткой.

← →
Медвежонок Пятачок © (2010-03-22 12:44) [27]

длинные целые в дотнете
http://www.codeproject.com/KB/cs/biginteger.aspx
наверняка их есть еще

← →
KSergey © (2010-03-22 12:45) [28]

> Думкин © (22.03.10 10:47) [16]

Все люди братья, ты не знал?

← →
Anatoly Podgoretsky © (2010-03-22 12:47) [29]

> Медвежонок Пятачок (22.03.2010 12:21:25) [25]

Это не желательно, это будут пляски с бубном.

← →
test © (2010-03-22 13:25) [30]

Медвежонок Пятачок © (22.03.10 10:49) [17]
MySQL это если монетка к русалкам упадет, PostgreSQL само то, там правда все равно уход будет нужен, если на ура лишь бы было то Firebird он более неприхотлив.

← →
Petr V. Abramov © (2010-03-22 13:29) [31]

> Вы бы доверили базу Oracle администрировать студенту, если
> интересует результат?

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

← →
Медвежонок Пятачок © (2010-03-22 14:02) [32]

лучшая субд для научных проектов - это адабас на ес1036.
фик уже кто внутрь залезет и проверит на что ушли бабки.

← →
GDI+ (2010-03-22 14:55) [33]

> Медвежонок Пятачок © (22.03.10 12:44) [27]
>
> длинные целые в дотнете
> http://www.codeproject.com/KB/cs/biginteger.aspx
> наверняка их есть еще

Тоесть по поводу наличия библиотеки на Delphi вопрос слит?

← →
Медвежонок Пятачок © (2010-03-22 14:58) [34]

да есть они и для делфи.

> мультиплатформенности не нужно, но работоспособность на
> трёх основных ОС (Windows, MacOS, Linux) должна быть.

Суупер! Это надо запомнить :)

> tesseract © (22.03.10 10:10) [14]
>
>
> > подключать высокопроизводительные библиотеки на С++ и
> иметь
> > готовую библиотеку математических функций (для предварительных
> > вычислений во время выборки данных).
>
>
> Ээээ, а чай приносить СУБД не должна ? Вычисления - задача
> не СУБД, а клиента.

Не согласен. Специфика везде своя. PostgreSQL умеет подключать функции на С, с 9.0 обещают поддержку С++...

> PEAKTOP © (21.03.10 23:45) [9]

> Лично я за ЖарПтица (потому, что в этой команде). Но и Слонопотам
> с этим справиться без проблем (новости оттуда изучаю регулярно
> - как-никак конкурирующий продукт).
>

Привет конкурентам. ;) Впервые слышу, что Псису и Слона считают конкурентами. Это может на постсоветском пространстве? Ибо от буржуев ниразу не слышал такого.

> PostgreSQL умеет подключать функции на С,

И interbase может. А есть ли СМЫСЛ? Если нужны подобные расчеты - не проще ли не конопатиться и написать адекватную и намного более логичную двухзвенку ? Или хранить данные в табличках промежуточных рассчетов- как делается при любых векторных расчетах - а 70 % подобных баз содержат данные как-раз для статистических анализов.

> Привет конкурентам. ;) Впервые слышу, что Псису и Слона считают конкурентами

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

У вас (Слоноводов) есть свои сильные и слабые стороны, у нас (Птицеводов) тоже. Но мы все развиваемся, а значит - коммунизм на горизонте =) (Горизонт - воображаемая линия между небом и землей, которая равномерно удаляется от нас, по мере того, как мы к ней приближаемся)

Конечно, многие вещи у вас не дают спать спокойно. Например, документация, на которую я уже не первый год облизываюсь. Но и у нас уже есть http://firebirdsql.su, а вот недавно было принято решение добавить туда многоязычный плагин. Но все равно пока еще до уровня postgresql.chm далеко, потому как с русской и португальской(бразилийской) версией справки вроде вопросов нет, а вот кто будет модерировать английскую (и считай основную) ветку документации - до сих пор неизвестно.

Внешние ХП на других языках программирования - тоже интересная вещь. У нас будет в 3.0 после обратного портирования исходников из "подпроекта" RedDatabase.

Но зато мы более лояльно относимся к "слабому" железу, я имею в виду производительность в целом, а не просто "взлетит-не взлетит". И Embedded у нас тоже есть - а значит можно не озадачивать юзера вопросом "что такое установка SQL-сервера".

В общем, давайте жить дружно =)

> PEAKTOP (24.03.2010 04:47:39) [39]

Которое лежит рядом с программой? Или как?

> Паш, я знаю, что ты по Снонопотаму "зажигаешь", поэтому
> холиварить не будем :)

Да я ж никогда! :) Мир, дружба, жвачка!

> Но зато мы более лояльно относимся к "слабому" железу, я
> имею в виду производительность в целом, а не просто "взлетит-
> не взлетит".

На слабом железе можно собрать слона с нужными настройками. Но смысл?

> И Embedded у нас тоже есть - а значит можно не озадачивать
> юзера вопросом "что такое установка SQL-сервера".

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

> В общем, давайте жить дружно =)

Давайте! :)

> tesseract © (23.03.10 21:57) [38]
>
> И interbase может. А есть ли СМЫСЛ? Если нужны подобные
> расчеты - не проще ли не конопатиться и написать адекватную
> и намного более логичную двухзвенку ?

Тут вопрос как бы немного в другом. Например, триггеры на С явно быстрее, чем на хранимых языках. А триггер это часть серверной логики, как ни крути.

Аггрегатные функции тоже часть серверной логики. Всё упирается в планирование.

> Например, триггеры на С явно быстрее, чем на хранимых языках.

На С скомпилированных, или на С-Script? В принципе триггеры должны компилироваться и не терять в производительности. Хотя тут бабка натрое сказала - в логику работы БД нужно смотреть.

> tesseract © (24.03.10 18:42) [43]

Скомпилированные, конечно. Пример:
CREATE OR REPLACE FUNCTION euc_cn_to_utf8(integer, integer, cstring, internal, integer) RETURNS void AS "$libdir/utf8_and_euc_cn", "euc_cn_to_utf8" LANGUAGE "c" VOLATILE STRICT COST 1;

$libdir/utf8_and_euc_cn - библиотека с функцией. В случае с Виндой utf8_and_euc_cn.dll, в случае с Линями utf8_and_euc_cn.so

euc_cn_to_utf8 - имя функции

DECLARE EXTERNAL FUNCTION bin_xor INTEGER, INTEGER RETURNS INTEGER BY VALUE ENTRY_POINT "IB_UDF_bin_xor" MODULE_NAME "ib_udf";
А зачем триггер-то на С писать? ЧТо быстрее будет - так очень вряд ли.

pasha_golub © (25.03.10 12:58) [44]
> Скомпилированные, конечно. Пример:

А ты часом функции ни с чем не попутал ?

Внешние функции (UDF - User Defined Functions), которые подключаются из DLL/SO - это одно, это было реализовано еще даже не в Firebird, а в дедушке InterBase.
А вот хранимые процедуры/триггеры/PSQL-блоки на внешних языках - это совсем другое. Например, как у вас (Слоноводов) это сделано на Перловке или Питоне.
CREATE FUNCTION pymax (a integer, b integer) RETURNS integer AS $$ if (a is None) or (b is None): return None if a > b: return a return b $$ LANGUAGE plpythonu;
или
CREATE OR REPLACE FUNCTION valid_id() RETURNS trigger AS $$ if (($_TD->{new}{i} >= 100) || ($_TD->{new}{i} <= 0)) { return "SKIP"; # skip INSERT/UPDATE command } elsif ($_TD->{new}{v} ne "immortal") { $_TD->{new}{v} .= "(modified by trigger)"; return "MODIFY"; # modify row and execute INSERT/UPDATE command } else { return; # execute INSERT/UPDATE command } $$ LANGUAGE plperl;

> блоки на внешних языках - это совсем другое.

Фактически то-же самое. Какая разница как функция прилинкована - динамически или статически - она всё равно функция.

> PEAKTOP © (25.03.10 16:52) [46]

> А ты часом функции ни с чем не попутал ?

Не попутал. :) Функция есть функция. А вот триггер в контексте Постгреса - это событие, которое вызывает функцию-обработчик:

CREATE FUNCTION trigf() RETURNS trigger AS "filename" LANGUAGE C; CREATE TRIGGER tbefore BEFORE INSERT OR UPDATE OR DELETE ON ttest FOR EACH ROW EXECUTE PROCEDURE trigf();

> А вот триггер в контексте Постгреса - это событие, которое вызывает функцию-обработчик:

А все, понял. Это просто произошла "подмена понятий" =)

у нас это блок (в данный момент писанный только на SQL), который будет выполнен при вставке/изменении/удалении строки. По сути, от ХП или PSQL-блока он ничем не отличается.

CREATE OR ALTER TRIGGER <TRIGGER_NAME> FOR <TABLE_NAME> [ACTIVE | INACTIVE] {BEFORE || AFTER} {INSERT | UPDATE | DELETE} [POSITION number] AS BEGIN <TRIGGER_CODE>... END

Лучшая СУБД для научных проектов. Найти похожие ветки