Переход с IB на Oracle

← →
GreSt (2003-04-09 07:54) [0]

Всем привет!
Стоит задача оценить возможность перехода с IB на Oracle.
К сожалению доступная(в обозримом простанстве) литература по Oracle раскрывает исключительно вопросы администрирования.
Из того что мне удалось найти я вижу проблемы с
1. типами данных - отсутствует целочисленные типы(INTEGER).
2. процедурами выбора - по крайней мере я не нашел как можно выкрутится.
3. Объединения таблиц - странный синтаксис объединения таблиц с использованием (+) вместо Join.
Наверняка есть и другие проблемы.
Есть здесь люди хорошо знающие и IB и Oracle готовые консультировать при необходимости?

← →
Geka © (2003-04-09 08:29) [1]

В Оракл можно сделать практически все, что надо вообще делать с БД. NUMBER может быть и без плавающей точки, и остальное найдешь

← →
Big_Rom © (2003-04-09 08:54) [2]

Я добавлю некоторые вещи можно другими способом решить
так скажем по оракляному. В любом случае по потеть придется, но
проект от этого только выиграет :))

← →
Sergey13 © (2003-04-09 08:55) [3]

2GreSt (09.04.03 07:54)
>К сожалению доступная(в обозримом простанстве) литература по Oracle раскрывает исключительно вопросы администрирования.

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

>1. типами данных - отсутствует целочисленные типы(INTEGER).
Все там есть. И все корректно работает в отличии от ИБ.

>2. процедурами выбора - по крайней мере я не нашел как можно выкрутится.
В 9 (читал, но не работал) совсем просто стало. В 8 немного через задницу, но если один раз поймешь как - проблемы не будет.

>3. Объединения таблиц - странный синтаксис объединения таблиц с использованием (+) вместо Join.
А вот тут совсем непонятно. В оракле по сравнению с ИБ это как раз намного проще. С нужной стороны (+) поставил и все. Не стандартно (SQL92), но просто и со вкусом.

>Наверняка есть и другие проблемы.
Наверняка есть, но они решаемые. Минус только один - ЦЕНА.

>Есть здесь люди хорошо знающие и IB и Oracle готовые консультировать при необходимости?
Все зависит от вопросов и частоты их задавания. 8-)
Есть хорошие форумы КОНКРЕТНО по Ораклу. Например на SQL.RU

Я бы посоветовал (если вы СЕРЬЕЗНО заняты этой проблемой) послать кого нибудь учиться на курсы. Самостоятельно разобраться с Ораклом достаточно трудно (мягко сказано). Даже чтобы правильно вопрос задать. 8-)

← →
EthernalWonderer (2003-04-09 09:21) [4]

>GreSt (09.04.03 07:54)
>Всем привет!
>Стоит задача оценить возможность перехода с IB на Oracle.

Надо бы допросить у того, кто ставит ТАКИЕ задачи, готов ли он (1) обосновать их необходимость хоть чем - то
(2) заплатить за ПО, новое железо, обучение персонала, плюс скрытые расходы (освоение, простой при переходе, доработка клиентского ПО, увеличение зарплаты персонала и т.д).

← →
GreSt (2003-04-09 09:24) [5]

Спасибо всем ответившим. Даже не надеялся что ответы будут:)

С курсами мысль хорошая, но заказчик должен принять решение, а я должен его убедить:)

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

Сейчас надо именно оценить трудности переноса структуры базы и модификации клиентской программы.

Есть ли другие проблемы переноса, кроме тех что я перечислил?
Заранее спасибо всем.

← →
Johnmen © (2003-04-09 09:59) [6]

Очень важно продумать т.н. "совместимость". Нужна ли она ? Что это даст (объективно) ? И почему так категорично "Причем на всех платформах должен работать один EXE-шник" ? Какой в этом глубокий смысл ?
А по поводу JOIN, так появилась вроде бы такая нотификация в 9.

В целом - готовь бабки, причем немалые бабки :)))

← →
Sergey13 © (2003-04-09 10:48) [7]

2GreSt (09.04.03 09:24)
>С курсами мысль хорошая, но заказчик должен принять решение, а я должен его убедить:)
А надо ли вообще, и кому надо?

>При переходе необходимо оставить совместимость с IB и MS
Для совместимости нужно или полностью копировать функционал серверного кода, либо полностью от него отказаться.

>Причем на всех платформах должен работать один EXE-шник
Если волнуют именно ПЛАТФОРМЫ, то ИМХО это не Делфи а на жабе наверное писать надо. Если волнуют все БАЗЫ - ИМХО это утопия.

>В этом смысле синтаксис объединений создает проблемы.
А кто говорил что это легко. И если б только синтаксис. 8-(
Вообще, что за задача такая? Ваша контора решила юзать Оракла или вы пишите некий продукт и хотите чтоб оно работало на всем что шевелится?

>По поводу администрирования - на данном этапе это не актуально.
А зря, ИМХО. Это один из главных доводов против Оракла. Хотя если ты собираешся говорить за него, то конечно. 8-)

← →
id_privin © (2003-04-09 12:17) [8]

Все что скажу - сугубо личное мнение не претендующее на объективность.

1) Oracle может в 10 раз больше чем IB
2) Oracle намного устойчивее IB
3) под Oracle намного удобнее писать.
4) освоить Oracle в объеме достаточном для разработки, можно самомтоятельно примерно за 1000р (две хорошие книги)
5) Oracle жрет несравнимо больше ресурсов и дико сложен в администрировании. Но админ - это отдельный человек, которуму платит клиент. А в процессе разработки особое администрирование не требуется.

← →
GreSt (2003-04-09 12:28) [9]

2Sergey13
Скажем так, есть организации работающие на нашей проге, которые требуют(точнее просят) чтобы она поддерживала Oracle.
Вопросы администрирования меня будут касаться минимально.
В любом случае поддержка MS и IB должна остаться, т.к. есть другие организации которых устраивает IB или MS и их гораздо больше чем Oracl-истов и естественно их надо поддерживать, плодить несколько вариантов исходных текстов нежелательно, даже если делать 3 EXE-ника, но это второстепенный вопрос. Про EXE-шник я написал чтобы пояснить вопрос совместимости разных диалектов SQL. Вопросы технологии кодирования несколько далеки от того что меня интересует.
А интересуют меня потенциальные подводные камни, и чем ближе я буду к истине тем более реальные сроки и деньги смогу назвать руководству. А оно будет принимать решение делаем или нет:)
Естественно мне не хочется оказаться в роли крайнего:)
Сейчас понятно что придется перед выполнением Select, Update, Delete конвертировать текст запроса.
Если NUMBER может быть использован как INTEGER то остается вопрос
TIntegerField для этого годится или нужен будет TFloatField
И прочие аналогичные вопросы.
Ситуация ослажняется тем что у меня нет никакого дистрибутива Oracle, и минимум литературы, да и та что есть мне не помогает.
И я не в Москве, пойти в такой-то магазин не смогу:)
В отличии от специализированных форумов, я надеялся найти здесь людей переносивших программы с IB на Oracle которые смогут поделится опытом.
Даже минимальное перечисление проблем с кратким пояснением меня устроит.
А если будет принято решение - делаем, тогда будет другой разговор.
А сам я за или против даже не знаю, очень высока вероятность что рано или поздно делать придется.
Насчет утопии не знаю, по крайней мере совместить IB и MS удалось. Если это принципиально невозможно, хочется знать почему, из того что я знаю принципиально невозможного нет.

← →
Sergey13 © (2003-04-10 10:19) [10]

2GreSt (09.04.03 12:28)
>Скажем так...
Ну вот теперь многое становится понятным. И все мои "наезды" снимаются. Хоть и не хотел я вовсе наезжать. Не обижайся.

К сожалению опыта именно переноса с ИБ на Оракл у меня нет. Хотя работаю с обеими БД.
Наверное соответствия типов NUMBER и INTEGER добиться можно. При использовании одинаковых компонент доступа. Хотя на 100% не поручусь за это т.к. для связи с этими БД я использую разные компоненты доступа.
По моему однозначного ответа ты не получишь нигде. А если и получишь, то я бы ему особо не доверял. Так как для этого надо конкретно ковырять твою программу и смотреть что и как работает. Так что скорее всего пока не попробуешь - не узнаешь.

>Естественно мне не хочется оказаться в роли крайнего:)
Жизнь учит готовиться к обратному. 8-( Начальство принимает решение, а воплщают в жизнь его простые смертные.

И про администрирование. За MS не скажу (не юзал) а с Ораклом дело обстоит примерно так. Если на этапе проектирования/написания приложения не думать о нем, то на выходе можно получить еще того монстра, который будет вешать сервер на раз. Я так понял, что ораклиные конторы-заказчики уже имеют его(оракла) и хотят встроить вашу БД в свои сервера. Я бы поговорил с их админами/разработчиками, показал им свои сырцы. Что они скажут-посоветуют. А то я так думаю они тоже не в восторге от такого слияния.

← →
GreSt (2003-04-10 15:54) [11]

2Sergey13 © (10.04.03 10:19)
А я и не обижаюсь:)
Сам виноват, надо было конкретней писать:)
Да действительно, желающие уже имеют Oracle.
Если придется экспериментировать проконсультируешь как "через задницу":) эмулировать процедуры выбора? Доставать не буду:)

← →
EthernalWonderer (2003-04-11 09:57) [12]

Есть красивое решение для такой задачи:
вынос всех компонентов типа Session, Query, DataSet
в dll и поддержка разных версий dll для разных клиентов.

При этом пишется некий набор типовых функций, возвращающих
данные из dll по запросам основной программы (т.н. внутренний интерфейс). В каждой из dll реализованы обращения к
соответствующей СУБД с её "странностями".

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

PS. Это называется Plug-in

2EthernalWonderer (11.04.03 09:57)
Где то я читал про траблы с датасетами из длл (сам не пробовал - потому не утверждаю что это так). Поэтому я бы предложил примерно то-же, но по другому. Все ДБ-компоненты собрать в отдельном датамодуле - оригинальном для каждой базы. При одинаковости имен и функционала просто для каждой базы компилировать со своим модулем. Все равно для 1 клиента должна быть 1 база.

2GreSt (10.04.03 15:54)
>Доставать не буду:)
ну, если не будешь, то попробую 8-) Но предупреждаю - я не гуру в Оракле (да и вообще не гуру 8-).

>Причем на всех платформах должен работать один EXE-шник
Может условная компиляция компиляция тебя спасет?
{$IFDEF ORACLE} sql :="INSERT INTO MyTable(DATA) VALUES (SYSDATE)"; {$ELSE} sql :="INSERT INTO MyTable(DATATYP VALUES (GETDATE())"; {$ENDIF}

← →
EthernalWonderer (2003-04-11 11:45) [15]

Sergey13 © (11.04.03 10:42)
Я как-то использовал такой вариант, и не сказал бы, что есть какие-то серьёзные проблемы с его реализацией. На форуме появляются вопросы по этому поводу, но все они легко решаемы.
Вот с формами в dll действительно есть проблемы и ограничения.

А что касается 1 клиента для 1 базы, то я как раз понял проблему наоборот - с 1 клиента получить доступ к любой базе

Переход с IB на Oracle Найти похожие ветки