Схемы логической группировки в ORACLE?

Question

Мы планируем новую систему для клиента в ORACLE 11g.Я был в основном в мире Sql Server в течение нескольких лет, и я не в курсе последних обновлений ORACLE.

Одна особенность, которая меня интересует, добавил ли ORACLE к этому моменту, является своего рода логическим «контейнером» для объектов базы данных, похожим на SCHEMA Sql Server.

Попытка использовать схемы ORACLE, такие как Sql Server, приводит к катастрофе при сравнении кода при попытке перейти из dev> test> live.

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

Единственный другой вариант, который мне известен, - это архаичная практика, состоящая в том, что нужно префиксировать имена объектов префиксом "схемы", то есть RPT_ REPORTS , RPT_ PARAMETERS, RPT_ LOGS , RPT_ USERS , RPT_ RUN_REPORT () , с префиксом RPT_, обозначающим, что это всеговорят объекты, связанные с нашим механизмом отчетности.При написании подобной системы создается ощущение, что мы никогда не покидали эпоху имен файлов 8.3.

Есть ли к этому моменту какой-либо более чистый, более прямой способ логической группировки связанных объектов в ORACLE?

Answer 1

Логический контейнер Oracle для объектов базы данных является схемой. Я не знаю, сколько "чище" и "прямее" вы можете получить! Вам придется сделать здесь смену парадигмы. Не пытайтесь мыслить терминами SQL Server и предлагайте решение, которое выглядит как SQL Server в Oracle. Ознакомьтесь с тем, что делает Oracle, и подойдите к своим проблемам с этой точки зрения. Не должно быть никаких проблем с переходом с dev на тестирование на производство в Oracle, если вы знаете, что делаете.

Похоже, у вас на плечах немного об Oracle, когда вы используете такие термины, как "архаичная практика". Я бы посоветовал вам подружиться с очень богатым и мощным набором функций Oracle, немного почитав, так как вы, очевидно, уже привержены Oracle для этого проекта. В частности, подберите копию «Эффективного Oracle By Design» Тома Кайта. Как только вы прочитаете это, взгляните на «Экспертную архитектуру базы данных Oracle» того же автора, чтобы более подробно рассмотреть, как работает Oracle. Вы в долгу перед своим клиентом, чтобы знать, как использовать инструмент, который вам передали. Кто знает? Тебе это может даже понравиться. Думайте об этом как о другом инструменте в вашем инструменте. Вы не состоите в браке с SQL Server и не изменяете, используя Oracle; -)

EDIT:

В ответ на вопросы ОП:

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

Если вы хотите «красивую, автономную базу данных», как SQL Server, просто создайте одну схему для хранения всех ваших объектов. Конец проблемы. Вы можете создавать других пользователей / схемы, просто не позволяйте им создавать объекты.

Существуют инструменты для сравнения объектов и данных, как в PL / SQL Developer Сравнение. Обычно в Oracle вы хотите сравнивать схемы, а не целые базы данных. Я не уверен, почему вы хотите иметь несколько схем, каждая из которых имеет свои собственные объекты в любом случае. Что покупает, чтобы сделать это? Храните ваши объекты (таблицы, триггеры, код, представления и т. Д.) В одной схеме.