Рефакторинг базы Oracle

← →
Ломброзо © (2006-12-17 21:59) [0]

Встала задача интегрировать некую доселе отдельно стоящую схему A с некоей основной схемой B. Проблем сразу несколько:

1) В схеме B принято соглашение об именовании объектов с использованием префикса, который определяет некое логическое пространство, ну например, "LAB_" - лаборатория и т.п. В схеме А никаких префиксов нет.

В рамках предварительных работ по переименованию объектов эту задачу в черновом виде я решил, слив обе схемы в одну, сгенерировав в основной схеме для всех таблиц схемы А вьюшки-"заглушки" с префиксами и перенаправив все обращения к таблицам из функций и хранимых процедур к этим заглушкам.
Отладил сервер приложений и клиентов. Вроде ничего не падает, но беда в том, что для сервера приложений написано много кода, работающего с таблицами не через ХП, а напрямую, и я боюсь, что что-то упустил, хотя часть кода уже исправлена поиском и заменой текста. Хотелось бы каким-то образом запретить возможность чтения и записи непосредственно из таблиц, дабы выявить эти куски при тестировании. Подозреваю, что это можно сделать настройкой прав, но пока не знаю как.

2) Решил извести гуиды (CHAR(32)) в качестве первичных ключей.
Все столбцы-PK у меня именуются ID.
Тактический план таков:
- Сгенерировать для всех таблиц поле NID NUMBER(19) - служебное для хранения новых ключей
- Сгенерировать для всех таблиц поле GUID, куда скопировать старое значение первичного ключа, то есть ID
- Сгенерировать для всех таблиц сиквенсы и заполнить поля NID новыми значениями PK
- Сгенерировать для всех таблиц триггеры на вставку значения счётчика

Это всё уже проделано. Загвоздка в том, что мне нужно сменить тип данных для всех столбцов, включенных в PK и FK, то есть удалить поле ID в каждой таблице, переименовать поле NID в ID, сменить тип данных столбцов в подчинённых таблицах и обновить в них же значения внешних ключей. Существуют ли в природе какие-нибудь утилиты для того, чтобы проделать манипуляции с изменением типов и каскадным обновлением связей максимально безболезненно?

← →
kaif © (2006-12-17 22:11) [1]

Как это народ любит в оракле всякие NUMBER(19) - я фигею.
Неужели integer-а (4 байта) не хватает?

Существуют ли в природе какие-нибудь утилиты для того, чтобы проделать манипуляции с изменением типов и каскадным обновлением связей максимально безболезненно?

Безболезненно для данных или для чего безболезненно?
Я бы создал бекап сталой базы.
Затем создал бы новые таблицы (возможно в новой базе даже) с помощью некоторого сценария, а инфу из старых - просто перегнал в новые какими-нибудь
INSERT INTO ... SELECT ... FROM.

← →
Sergey Masloff (2006-12-17 23:10) [2]

kaif © (17.12.06 22:11) [1]
Как это народ любит в оракле всякие NUMBER(19) - я фигею.
>Неужели integer-а (4 байта) не хватает?
А что-хватает? Мне давно не хватает.
Но вообще это от лукавого. Надо NUMBER просто писать и не париться. Если конечно конкретный формат не диктуется задачей.

← →
Sergey Masloff (2006-12-17 23:12) [3]

А точно нужно схемы объединять? Может просто для всех объектов схемы B псевдонимов в A наделать и дело с концом. Тем более если это ЛОГИЧЕСКИ разные схемы. Так намного кошернее было б. Модульность системы и все дела.
Про таблицы - ривок селект для юзера грант селект хранимой процедуре. И все.

← →
Anatoly Podgoretsky © (2006-12-17 23:20) [4]

> Sergey Masloff (17.12.2006 23:10:02) [2]

Народ любит NUMBER(38)

← →
Petr V. Abramov © (2006-12-17 23:25) [5]

> грант селект хранимой процедуре.
это как??? такое вроде в IB/FB только

← →
evvcom © (2006-12-18 10:16) [6]

> [5] Petr V. Abramov © (17.12.06 23:25)

наверное имелось ввиду grant execute

← →
roottim © (2006-12-18 11:56) [7]

1. Если сервер приложений работает с таблицей - то в чем тут проблема ? Разве стоит задача "не работать с таблицей на прямую" ? Проблема была с префиксом и ты ее решил.
2. Надо еще GUID по FK сохранить, а дальше хорошая утилита sqlplus и pl/sql - для анализа

← →
Desdechado © (2006-12-18 11:57) [8]

kaif © (17.12.06 22:11) [1]
> Неужели integer-а (4 байта) не хватает?
И Oracle INTEGER - это псевдоним для NUMBER(38).

Sergey Masloff (17.12.06 23:10) [2]
> Надо NUMBER просто писать и не париться.
Это вот оно от лукавого. Числа с фиксированным форматом лучше поддаются оптимизации, чем с плавающей точкой. А для ID плавающую точку использовать - странность, если не сказать сильнее.

Sergey Masloff (17.12.06 23:12) [3]
А вот с этим согласен. Зачем все это сливать? Смысла не вижу.

← →
Sergey Masloff (2006-12-18 20:37) [9]

Desdechado © (18.12.06 11:57) [8]
>Это вот оно от лукавого. Числа с фиксированным форматом лучше >поддаются оптимизации, чем с плавающей точкой.
Работает одинаково. Тестировалось... А раз стоит одинаково то почему бы и нет... Насчет дробной части в ID тоже бывает полезно... Например хранить номер узла при двусторонней репликации. Конечно можно и по-другому но можно ж и так ;-)
Хотя уже в оффтоп пошли.

← →
Ломброзо © (2006-12-18 22:27) [10]

>Sergey Masloff (17.12.06 23:12) [3]
>А точно нужно схемы объединять? Модульность системы и все дела.

Модульность базы мы уже проходили. Долго рассказывать, но в итоге единую базу оказалось на порядок проще распространять и поддерживать. Модульность вынесена на уровень сервера приложений и клиентов. Один леший пустой кусок базы без логики надстройки для практического применения бесполезен, а места особо не жрёт.

Сегодня по одной извел все временные представления-заглушки и переименовал таблицы.

Вопрос о смене типа столбца остаётся открытым :) Я мыслил сделать как:
1) пусть у нас все PK - это строка(32).
2) включить в констрейнтах каскадное обновление и изменить первичный ключ-строку на соответствующее значение счётчика. По идее должны каскадно обновиться FK в подчиненных таблицах.
3) изменить тип данных PK и FK c char(32) на number .

Со вторым и третьим пунктом облом, поскольку функциональность 2) имеют MS SQL и Access, а в оракле я такой опции не нашёл. 3) можно сделать только если столбец пустой.

>Как это народ любит в оракле всякие NUMBER(19) - я фигею.
Неужели integer-а (4 байта) не хватает?

Каждому настоящему программисту хочется верить, что разработанной им БД будут пользоваться и через миллион лет ;o)

Даааа.. Зашел вот.. На фоне всяких там рентгеновских утюгов под столом и глазастых политковских как в оазис окунулся..
Приятно пообчаться с умными людями ;)))

← →
Sergey Masloff (2006-12-18 23:09) [13]

Lamer@fools.ua © (18.12.06 22:43) [11]
>Каждому настоящему программисту хочется верить, что разработанной им >БД будут пользоваться и через миллион лет ;o)
Мы за Int32 вывалились на пятом году. Так что про миллионы это очень оптимистично ;-)

← →
Sergey Masloff (2006-12-18 23:13) [14]

Ломброзо © (18.12.06 22:27) [10]
>2) включить в констрейнтах каскадное обновление и изменить первичный >ключ-строку на соответствующее значение счётчика. По идее должны >каскадно обновиться FK в подчиненных таблицах.
Сгенерить триггеры? В ERWine или на PLSQL на основе словаря данных?

А тип поля сменить не получится.
Наверное так:
1) дизейблишь все констрейнты
2) через временное поле перекидываешь данные делая им TO_NUMBER()
подробно не расписываю так как думаю тут все понятно
3) включаешь констрейнты

Должно получиться вроде бы.

>>Sergey Masloff (18.12.06 23:09) [13]

Вот я и говорю: даешь 512-битные числа, чтоб гугол влезал! :o)

Рефакторинг базы Oracle Найти похожие ветки