asd24Добрый день, коллеги.
насколько сложно переходить из MS SQL в Oracle?


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

SergSuperNitro_Junkieпропущено...


Прежде всего надо выключить логику, потому как иначе никаких нервов не хватит. Иногда кажется, что если что-то можно было сделать криво, индусы из Оракла это сделали.не, вот с таким подходом кульного хацкера - всё криво и писали неведомые индусы - надо бороться (хотя это тяжело)

Да дело не в этом. Логика instance'а и одной единственной базы в нем ни разу не логична (для баз в обычном понимании остальных sql серверов предлагают использовать схемы, что в замен схем предлагают неясно), как обновлять структуру БД с не транзакционным DDL'ом - тоже фиг поймешь, кривая модульная структура, когда не можешь сказать из-за отсутствия какой таблицы (причем судя по форумам у каждого своей) ты не можешь удалить схему (пользователя), ограничение на 30 символов для идентификатора в 21 веке. И это только первое что удалось раскопать при написании адаптера к нему. Представляю что будет дальше :(

vadiminfoПеревидите, плиз.


Ну в Postgresql, MSSQL и остальных. Для instance'а есть понятие база, то есть можно подключиться к instance'у и сделать скажем CREATE DATABASE X; CREATE DATABASE Y; потом USE X; и работать с базой X (не видя Y). А потом можно сделать DROP DATABASE X; и опять CREATE DATABASE X; И так сколько угодно раз.

То есть обычная схема работы любого приложения. Указал instance, приложение подключилось к нему, создало базу и поехало работать. В Oracle'е же такой стандартный кейс делается через одно место.

vadiminfo"не транзакционным DDL'ом " - т.е. может записать, например, в словарь, что таблица создана, но не записать про ее столбцы? Нарушить типа то, что должно быть аторманостью транзакции, если бы была "транзакционность" или что?


Нет это значит, что например мне нужно обновить структуру базы, скажем сделать CREATE A; CREATE B; а потом что-то рассчитать для B. И предположим расчет падает. Я фикшу ошибку и запускаю обновление структуры и что я вижу? Что таблица A already exists. То есть для целостного обновления базы, мне нужно самому эмулировать "транзакцию", то есть запоминать что я создал и если все обновление не завершилось успешно, вручную откатывать это изменение. Или везде вставлять дополнительные "ручные" проверки на целостность, что еще хуже.

Bogdanov Andreyмыслит парадигмами единственного любимого сервера.

В том то и дело что не любимого, а 90% остальных серверов (под 10% я подразумеваю MySQL). Да и вопрос не в остальных серверах, и не в присутствии workaroundов, а в том что возникает ощущение, что при выборе того как красиво реализовать ту или иную возможность архитекторы изначально выбирают более идиотское решение, чтобы увеличить порог вхождения. Ну и принципиальная позиция по ряду вопросов конечно напрягает. Вот что им мешает сделать нормальный UPDATE FROM... Религия? Причем чем дальше, тем больше возникает ощущение, что именно она.

rockclimberNitro_Junkieпропущено...


Ну в Postgresql, MSSQL и остальных. Для instance'а есть понятие база, то есть можно подключиться к instance'у и сделать скажем CREATE DATABASE X; CREATE DATABASE Y; потом USE X; и работать с базой X (не видя Y). А потом можно сделать DROP DATABASE X; и опять CREATE DATABASE X; И так сколько угодно раз. Это всего лишь ваше частное мнение. Я вот перешел на оракл с постгреса и вообще не вижу в этом проблемы (да и во всем остальном, что вы перечислили).

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

Basil A. Sidorov"Non-Oracle" схема работы может быть и плюсом и минусом.
Для разработчика может быть и плюс - переподключаться не надо, а вот на промышленном сервере - минус. И минус жирный.

В чем минус если не секрет?