<offtopic>

А посоветуйте на какую free СУБД лучше всего мигрировать с Oracle?
P.S. анонимусам просьба не беспокоиться.

</offtopic>

FireBird (клон interbase если кто не знает)

по возможностям наиболее полная postgresql

Зависти от того с какого Оракла. Если с <=7, то наверно лучше всего SAPDB, - которая нынче MySQL. Там есть режим полной совместимости со страрыми Ораклами. Если с более нового, да еще и pl/sql используюеся, то наверно пофиг на что переходить - больщую часть преписывать придётся.

А зачем с Oracle мигрировать ????

Не вводи в заблуждение. Firebird хороша сама по себе, но на замену Оракла явно не тянет.

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

а просто ради интереса, а дествительно чем Оракля то не угодила? Или только ценой?

В Postgres вроде был PL/SQL ? Может не полный, без пакетов, но был и не только он, там много чего есть :)

>Не вводи в заблуждение. Firebird хороша сама по себе, но на замену Оракла явно не тянет

Это утверждение достаточно абстрактно. Есть рабочие базы до 100 Гиг. Поддержка СКЛ-99, транзакции, триггеры, процедуры, джоины, классик поддерживает многопроцессорность... Если этого достаточно для решения задачи, то Firebird вполне подходит.

Spasibo za Patch

? a v Postgres eto vkluchat ?

MfG

Konstantin

Я конеш не авторитет по базам для многих тут, но вот моё мнение:
- Interbase полное убожество, наверное хуже СУБД не встречал (сужу по последней версии), SQL там НЕ ГИБКИЙ, все данные в одном файле
- PostgreSQL лучше Interbase
- про Firebird ничего не скажу
- в PostgreSQL многое сходно с Oracle, некоторые говорят, что версия PostgreSQL = версии Oracle (если не считать наворотов типа Warehouse ...), даже PL/pgSQL на 70% минимум соответствует PL/SQL
- в документации к PostgreSQL есть руководство по переходу с Oracle (достаточно хорошее, с описанием миграции процедур, запросов, перекачке данных и пр.)
- PostgreSQL используйте только >= 7.x.3 (значима последняя тройка), 7.4 еще недостаточно стабилен для production use.

> Interbase полное убожество
- гон
>SQL там НЕ ГИБКИЙ
- вам не достаточно SQL99 + UDF ?
> все данные в одном файле
- если прям так хочется БД можно распределить на
множество файлов всего их м.б. 65535 вопрос только в том
а нахрена это нужно если база в MAX_FILE_SIZE помещается?
(кстати файлы можно добавлять не прерывая работы юзеров)

> про Firebird ничего не скажу
- уж лучше и не говори

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

При переходе с Oracle не думаю, что UDF будет полезным подспорьем :) да и зачем переписывать то что уже сделано в других СУБД?
Там и так мало готового, а вы еще предлагаете людям компенсировать это переписывая проект (написав свои UDF процедуры), написанный для Oracle. Кстати UDF кросплатформенная фича? ;)
Interbase 7.0/Linux временные интервалы, тип bit, bool, int2, int4, int8, serial, timestamp с временной зоной не поддерживает - в ANSI SQL92 некоторые кстати определены :), с ODBC 3.0 совсем туго :P
Хочется не перераспределить на множество файлов, а скажем вынести индексы на другой RAID-массив :) для ускорения работы большой базы. К тому же часто так бывает, что при ошибке файловой системы гораздо больше шансов сохранить хоть что то, когда все не в однм файле, а в нескольких.

Был бы Interbase под рукой, я бы еще тут накумекал :) Особенно написал бы пару SQL-выражений, простейших довольно-таки, отказ принимать которые Interbase-ом, вызвал бы большое удивление у специалистов по крупным СУБД.

А как народ без exception обходится в PG?

Конеш гон, я малость выпил поэтому примерчик на закуску, тем, кого мне не догнать :) уважаемым anonymouse-ам
Interbase 6.0/Linux (ну только он оказался под рукой):
CREATE DATABASE '/opt/interbase/saper';
CONNECT '/opt/interbase/saper';
CREATE TABLE T1 (X1 INT, X2 INT);
INSERT INTO T1 VALUES (1, 1);
INSERT INTO T1 VALUES (2, 2);
INSERT INTO T1 SELECT * FROM T1;
Всё привет интербейзу? ;)
Советую перед примерчиком сохраниться, а то можете что-нибудь потерять на сервере, и клиенты скорее всего отвалятся.

P.S. saper .oO Если будут упорствовать надо попробовать под простым пользователем тоже самое, а потом еще view посоздавать :)

ltrim/rtrim - в UDF, а не в самой базе? ну-ну :)))

P.P.S. Мои посты не стоит рассматривать как попытку развести флейм или принизить возможности Interbase, потому что для своих задач (маленький такой, но Клиент-Сервер Interbase идеально подходит), а доказывать мне или специалисту, что он что то может в проектах на замену Oracle - бесполезно. При условии, что Oracle не ниже 7 версии, и что этот Oracle выбрали специалисты, а не менеджеры, которые и на склад поставят отдельный Oracle с репликацией :)

saper (*) (09.12.2003 8:42:21):
INSERT INTO T1 SELECT * FROM T1;


А почему не сразу rm -rf / ?

Очередной умник, блин.

>которые и на склад поставят отдельный Oracle с репликацией :)

А почему бы благародному дону не поставить на склад оракл с
репликацией? Или со Sream-ами? для полного и глубокого контроля
над тем что там в этом складе творится?

> А посоветуйте на какую free СУБД лучше всего мигрировать с Oracle? P.S. анонимусам просьба не беспокоиться.

Извини, тёзка, что я побеспокоился. Тебя спрашивали уже "зачем?" Ну я пойму, если новый проект делать не на оракуле. Но зачем работающие переделывать?

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

Народ! Все вы в корне не правы. Давеча мне один спец долгое время доказывал, что на самом деле (я то этого не знал) самые крутые базы это Access и MSSQL. А Oracle - вообще полный отстой, так как он глючный, неустойчиво и криво работает.

PS. PostgreSQL "native port for Windows" (как то говорили что такое есть) кто-нибудь юзал? Поделитесь ощущениями.

> К стати. Лучше оракула всё-равно ничего не найдёшь. Не хуже (в специфических случаях) может быть, но лучше - нет.

Спорно. Вот специалисты той же Интерсистемз утверждают, что делали они Оракл при запросах к большой базе данных. Так что фик его маму знает.

> Спорно.

Согласен. Можно подготовить "тест", в котором его "сделает" и MySQL.

А ларчик открывался просто.

saper (*) (09.12.2003 8:42:21):
INSERT INTO T1 SELECT * FROM T1;

highlander (*) (09.12.2003 9:30:16):
А почему не сразу rm -rf / ?
Очередной умник, блин.

highlander (*) (09.12.2003 9:30:16)
Имеется в виду, что на PostgreSQL данный запрос выполняется корректно.

>Зачем переписывать то что уже сделано в других СУБД?
- это не ко мне
>Interbase 7.0/Linux временные интервалы, тип bit, bool, int2, int4,int8, serial, timestamp
- см. диалект 3. см. UDF
> с ODBC 3.0 совсем туго
- не проверял, знаю что на сервере FireBird есть драйвера для ODBC

>Хочется не перераспределить на множество файлов, а скажем вынести >индексы на другой RAID-массив :) для ускорения работы большой базы.
- Ну и как ускоряет? быстрее чем RAID0 уровень + _много_ SCSI?

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

> Кстати UDF кросплатформенная фича?
- если писать на С кросплатформенно, то - да
для UDF в большинстве случаев получается
писать _именно_ кроссплатформенно

P.S.
Данные коментарии прошу воспринимать не как попытку
доказать, что InterBase САМЫЙ КРУТОЙ SQL СЕРВЕР, а
как попытка доказать, что InterBase и его совместимые
аналоги далеко не самые плохие сервера, а скорее даже
наоборот.



Реальный инструмент - для реальных задач.
Например имеется БД для хранения подробной статистики
squid. Размер файла БД 1Gb.
Записей в таблице статистики ~ 4 300 000


free
total used free shared buffers cached
Mem: 127360 123464 3896 0 1784 66764
-/+ buffers/cache: 54916 72444
Swap: 499688 3632 496056

model name : Pentium II (Deschutes)
stepping : 2
cpu MHz : 449.244
cache size : 512 KB

>Есть рабочие базы до 100 Гиг.
БЕЗ архивации логов, БЕЗ инкрементальных архивов, БЕЗ паралельного
восстановления ( например параллельного создания индексов и т.п. )
БЕЗ возможности загрузки/выгрузки базы в текстовом формате и т.п.
и т.д. 100G на Firebird или Interbase будет держать только самоубийца.


>Поддержка СКЛ-99, транзакции, триггеры, процедуры, джоины, классик
>поддерживает многопроцессорность... Если этого достаточно для решения
>задачи, то Firebird вполне подходит.

БЕЗ элементарного cost based оптимизатора, без нормального кэширования
( в classic например у каждой сессии свой кэш ) работать с 100G базой ?


Captain.

>Имеется в виду,
>что на PostgreSQL данный запрос выполняется корректно.

Корректно, это в цикле вставляет таблицу саму в себя в бесконечном цикле или как?

> стати. Лучше оракула всё-равно ничего не найдёшь

Смотря из чего выбирать. Мне например Informix или DB2 больше по вкусу.

Captain.

olleg (*) (09.12.2003 11:18:38) Имеется в виду, что на PostgreSQL данный запрос выполняется корректно

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

INSERT INTO A SELECT * FROM A - известная бага ИБ. Везде написано, что так делать не надо.

А в целом - jedem das seine. Для одной задачи хорош ИБ, где-то Постгрес. Куда-то нужно ставить Оракл. Только решать, что именно нужно ставить, должны не манагеры за откат, а совсем другие спецы.

>>Есть рабочие базы до 100 Гиг. >БЕЗ архивации логов, БЕЗ инкрементальных архивов, БЕЗ паралельного восстановления ( например параллельного создания индексов и т.п. ) БЕЗ возможности загрузки/выгрузки базы в текстовом формате и т.п. и т.д. 100G на Firebird или Interbase будет держать только самоубийца.

Ну, эти самоубийцы работают в банках США. Бэкап идет без остановки сервера. Есть зеркалирование. Инкрементальный бэкап - про него спорили, нужен ли. Делают.

>Поддержка СКЛ-99, транзакции, триггеры, процедуры, джоины, классик >поддерживает многопроцессорность... Если этого достаточно для решения >задачи, то Firebird вполне подходит.

>БЕЗ элементарного cost based оптимизатора, без нормального кэширования ( в classic например у каждой сессии свой кэш ) работать с 100G базой ?

Оптимизатор в Firebird 1.5 почти всегда выбирает оптимальный план по сравнению с ИБ или ФБ 1. Классик не имеет общего кеша, это да. В версии 2 собираются сделать многопроцесссорный суперсервер и классик с поддержкой общего кеша. Но это опять же, нужно людям с очень большими базами и загрузкой сервера. ОЧЕНЬ БОЛЬШИМИ. Для абсолютного большинства задач это не нужно - достаточно или суперсервера или многопроцессорного классика.

Еще раз хотелось бы подчеркнуть, что если у Вас база до 100 Г :) (требует конечно плясок с бубном), а лучше до 20 Гиг и не нужно одновременно больше 200 активных соединений, то существующий Firebird 1.5 ВПОЛНЕ С ЭТОЙ ЗАДАЧЕЙ СПРАВЛЯЕТСЯ.

>Captain.

"амые крутые базы это Access и MSSQL" - А ведь он прав ;-))))

У Oracle под winXXX действительно время от времени всплывают очень странные глюки. Другое дело, что сейчас под него выбирают чаще linux или unix.

2anonymous (*) (09.12.2003 6:45:36)
>А мне нравится БД в одном файле, а чем плохо?
Скоростью. Если в Oracle данные на одном массиве/диске, индексы на другом, роллбэки на третьем, где будет твой Interbase/Firebird на хотя бы 50 гиговой базе?

2anonymous (*) (09.12.2003 6:45:36)
Вдогонку ... а репликация или кластер на Interbase как? Interbase хорош для своих задач, Oracle для своих, не мешайте мух с котлетами
:-)

> Корректно, это в цикле вставляет таблицу саму в себя в бесконечном цикле или как?
Как в других базах: Informix, Oracle, DB2, PostgreSQL, Sybase - нужное подчеркнуть :) А что касается банков и баз на 100Гб, то что в этих базах хранится и не специальная ли там версия Interbase?

P.S. Раньше было можно PostgreSQLvsMySQL, теперь PostgreSQLvsInterbase, причем сторонники и тех и других претендуют на крупные корпоративные проекты :) А тут есть кто-нибудь из обсуждающих, кто делал такие проекты на Interbase или MySQL? Вот спросите у Korwin-а по поводу перехода с Oracle на PostgreSQL, что сказал заказчик, другие сотрудники, пишущие под эту базу, что ему как админу-программеру понравилось/непонравилось в таком переходе.

2saper
Ай! Могу сказать, что в живую видел банк который использовал MySQL. После мучений перешел на PostgreSQL и до сих пор доволен... Что на ней крутилось? Все, кроме бизнез-процессов, а это: ldap, icq, CMS, WEB projects и т.д.

база

> Записей в таблице статистики ~ 4 300 000
детский лепет.