Форум: "Базы";
Текущий архив: 2003.05.01;
Скачать: [xml.tar.bz2];
ВнизПереход с 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
← →
Sergey13 (2003-04-11 10:42) [13]2EthernalWonderer (11.04.03 09:57)
Где то я читал про траблы с датасетами из длл (сам не пробовал - потому не утверждаю что это так). Поэтому я бы предложил примерно то-же, но по другому. Все ДБ-компоненты собрать в отдельном датамодуле - оригинальном для каждой базы. При одинаковости имен и функционала просто для каждой базы компилировать со своим модулем. Все равно для 1 клиента должна быть 1 база.
2GreSt (10.04.03 15:54)
>Доставать не буду:)
ну, если не будешь, то попробую 8-) Но предупреждаю - я не гуру в Оракле (да и вообще не гуру 8-).
← →
NAlexey (2003-04-11 11:01) [14]>Причем на всех платформах должен работать один 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 клиента получить доступ к любой базе
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.05.01;
Скачать: [xml.tar.bz2];
Память: 0.5 MB
Время: 0.007 c