Построение БД Oracle; Хорошая Директория

Question

Я ищу совет о том, как лучше организовать новую схему Oracle и зависимые файлы в каталоге моего проекта - с последовательностями, триггерами, DDL и т. Д. Я использовал один монолитный файл под названием schema.sql для некоторых время, но мне интересно, есть ли лучшая практика? Что-то вроде ...

database/
   tables/
      person.sql
      group.sql
   sequences/
      person.sequence
      group.sequence
   triggers/
      new_person.trigger

Пенни за ваши мысли или URL, которые я, возможно, пропустил!

Спасибо!

Answer 1

Хранение DDL по типам объектов - разумный подход - во всем, вероятно, легче ориентироваться, чем в монолитном сценарии SQL.Лично я бы предпочел, чтобы DDL был организован по функциям.Например, если вы строите систему учета, у вас, вероятно, есть ряд объектов для управления кредиторской задолженностью и отдельный набор объектов для управления дебиторской задолженностью, а также некоторые основные объекты для управления счетами в главной книге.Это может привести к чему-то вроде

database/
  general_ledger/
    tables/
    packages/
    sequences/
  accounts_receivable/
    tables/
    packages/
    sequences/
  accounts_payable/
    tables/
    packages/
    sequences

Поскольку система становится все более сложной, эта иерархия, естественно, со временем будет становиться глубже.Такой подход более естественно отражал бы способ хранения кода, не являющегося базой данных, в системе контроля версий.У вас не было бы одного каталога Java-классов в структуре каталогов, подобной

middle_tier/
  java/
    Foo.java
    Bar.java

. Вы бы организовали классы, которые реализуют одни и те же виды бизнес-логики, вместе и отдельно от классов, которые реализуют разные кусочки бизнесалогика.

Answer 2

Следует учитывать один элемент SQL, который может выступать в роли скрипта «только для последних». К ним относятся СОЗДАНИЕ ИЛИ ЗАМЕНА ПРОЦЕДУРЫ / ФУНКЦИИ / ТРИГГЕРА и т. Д. Вы используете последнюю версию и не беспокоитесь о том, что ранее могло существовать в базе данных.

С другой стороны, у вас есть таблицы, с которых вы можете начать с CREATE TABLE, а затем нескольких ALTER TABLE по мере развития схемы. И если вы делаете обновление, вы можете применить несколько скриптов ALTER TABLE (желательно по порядку).

Я бы поспорил с «функциональной группировкой», если только на самом деле не очевидно, где нарисованы линии. Вы, вероятно, не хотите находиться в положении, когда у вас есть таблица USERS в одной группе и USER_AUTHORITIES в другой, а группа AUTHORITY в третьей.

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

Answer 3

В наших проектах мы используем несколько комбинированный подход: у нас есть ядро ​​нашей программы в качестве корня и другие функции в подпапках:

root/
  plugins/
    auth/
    mail/
    report/

и т.д.

Во всех этих папках у нас есть как DDL, так и DML-скрипты, почти все из них могут быть запущены более одного раза, например. все пакеты определены как create or replace..., все сценарии вставки данных проверяют, существуют ли данные, и так далее. Это дает нам возможность использовать почти все сценарии, не думая, что мы можем что-то сломать.

Очевидно, что этот сценарий не может применяться для create table и подобных операторов. Для этих сценариев мы вручную написали небольшой сценарий bash, который извлекает указанные файлы и запускает их без ошибок при определенных ошибках ORA, например: ORA-00955: name is already used by an existing object.

Также все файлы смешаны в каталогах, но различаются расширениями: .seq идет в последовательности, .tbl идет в таблице, .pkg идет в интерфейсе пакета, .bdy идет в теле пакета, .trg идет для запуска так далее ...

Также у нас есть соглашение об именах, обозначающее префиксы для всех наших файлов: у нас может быть таблица cl_oper.tbl с последовательностями и триггерами cl_oper.seq и cl_oper.trg и cl_oper_processing.pkg вместе с cl_oper_processing.bdy с логикой для упомянутых объектов. С этим соглашением об именах в файловых менеджерах очень легко увидеть все файлы, связанные с некоторой единицей логики для нашего проекта (в то время как группировка в каталогах по типам объектов не обеспечивает этого).

Надеюсь, эта информация вам как-то поможет. Пожалуйста, оставляйте комментарии, если у вас есть какие-либо вопросы.

Answer 4

Расположение по типу «объект по типу объекта» с добавлением каталога «схема» под каталогом базы данных хорошо работает для меня.

Я работал с системами контроля версий, в которых есть дополнительный слой с разделением по функциям - если имеется много объектов, добавляется дополнительный поиск, если вы пытаетесь сделать перекрестную ссылку на файл контроля версий с объектомчто вы видите в навигаторе GUI базы данных, который обычно группирует объекты по типу.Также не всегда понятно, как объект должен классифицироваться таким образом.

Рассмотрите возможность добавления каталога «грантов» для грантов, предоставленных этой схемой, в другие схемы или роли с одним файлом на грантополучателя.Если у вас есть «основанные на правилах» разрешения, такие как «роль APPLICATION_USER, всегда получает SELECT для всех таблиц схемы X», тогда напишите анонимный блок PL / SQL для выполнения этого действия.(Может возникнуть соблазн перепроектировать гранты после того, как они были введены в действие каким-то специальным методом, но легко пропустить что-то, когда в приложение добавляются новые таблицы или представления).

Стандартизация наразделитель для всех сценариев, и вы упростите себе жизнь, если начнете развертывать с помощью утилиты сборки, такой как Ant.Использование "/" (против ";") работает как для операторов SQL, так и для анонимных блоков PL / SQL.