Как работать с БД Oracle если имя схемы на этапе разработки не известно?

Question

Здравствуйте!

Как работать с БД Oracle (используя строгую типизацию данных) если имя схемы на этапе разработки не известно?

Это может понадобиться, например, при написании общего решения. Как заказчик назовёт схему в Oracle неизвестно. Кроме того, на одном экземпляре БД это решение может быть развёрнуто несколько раз в разных схемах. Структура  БД одинакова.

Посмотрел возможности ADO.NET, ADO.NET Entity Framework, LINQ to Oracle. Во всех реализациях имя схемы пишется константами в автогенерируемом коде и должно быть определенно на этапе разработки.

Answer 1

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

Answer 2

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

Есть какие-то идеи в какую сторону извращаться?
Сейчас перед билдом перегенерирую DataSet под конкретную схему.
Технически проблем реализовать хранение имени схемы набора данных в конфигурационном файле я не вижу. Всё что нужно - в существующих автогенераторах кода использовать не "schema1" а schemaname - константу. Почему это не реализуют разработчики framework-ов? Неужели нужно создавать свой велосипед "LINQ to Oracle" и прочие... С одним отличием: имя рабочей схемы - параметр.

Answer 3

Причём я так понимаю, в SQL Server такой проблемы нет, там в ConnectionString указывается Initial Catalog.
Всё правильно?

Answer 4

Странно... Тему перенесли в SQL Server...

Проблема для Oracle ещё актуальна. Пока склоняюсь к таким вариантам (на основе DataSet):

1. Дописывать partial адаптеры. Создать перегружаемый конструктор принимающий в качестве аргумента, например, OracleConnection. В этом же конструкторе заменять значения protected свойств (заменять имя схемы в sql команде).
+ Строгая типизация
— Много ручной работы
— Можно забыть (не знать) что нужно использовать конструктор с аргументом.

2. Написать код, который через рефлексию будет заменять имя схемы в sql команде protected свойства.
+ Мало ручной работы.
— Не строгая типизация. В случае перехода на новую версию .NET возможны проблемы.
— Можно забыть после создания адаптера вызвать код замены имени схемы и "помнить" её название.

3. Написать код, который будет при запуске приложения будет динамически менять код классов адаптеров (например, в конструктор по умолчанию добавит код коррекции имени схемы) и перекомпилировать его.
+ Вызывается только один раз.
+ Ручная работа практически отсутствует.
— Очень "низкий" уровень.
— Замедлит запуск приложения (время уйдёт на многократный запуск CSC).
— В случае перехода на новую версию .NET возможны проблемы.

Какие ещё — и + есть? По какому пути лучше пойти? У меня пока приоритеты такие: 3, 2, 1.

Но все эти варианты решения проблемы являются "заплаточными". Почему в ADO.NET этого не предусмотрели? Я не сомневаюсь в компетенции специалистов Microsoft. Видимо я чего-то не понимаю. Интересно, чего?

Answer 5

Остановился на варианте 2, т.к. не нашёл способа решения 3-го варианта.

Answer 6

не очень хорошо разбираюсь в оракл, но непонимаю почему нельзя просто заходить под разными логинами и не указывать имя схемы в тексте запросов pl/sql.