Константы уровня пакета в преобразовании Oracle в Postgres

Question

Я смотрю на преобразование приложения из Oracle в Postrges, которое имеет всю бизнес-логику в базе данных. В настоящее время существует очень большой пакет, содержащий около 200 открытых константных переменных. Postgres не поддерживает переменные уровня пакета, поэтому я обсуждаю, как его преобразовать. Я вижу две возможности, но мне нужно несколько мнений о том, что лучше (обе они кажутся очень противными):

1. Конвертировать каждую переменную в функцию, которая возвращает статическое значение. Это кажется наиболее вероятным, но кажется очень уродливым.
2. Составьте таблицу из значений. Проблема в том, что они используются в основном другими пакетами / функциями. Также есть сочетание типов (числовые против varchars).

Есть идеи?

Answer 1

Я бы смешал оба варианта. Параметры будут сохранены в таблице:

create table package_options ( option_name text, option_value text )

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

create function get_option(text) returns text as
$$ select option_value from package_options where option_name=$1 $$
language sql stable;

Также может быть get_int_option(text), преобразование значения в int и т. Д.

Вы также можете добавить option_type столбец и некоторые ограничения, которые будут проверять правильность типа.

Answer 2

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

В зависимости от использования вашей базы данных использование опции 2 может вызвать горячую точку в вашей базе данных. Вот более экстремальный сценарий - скажем, что у вас есть 5000 пользователей, вошедших в систему, которая в свою очередь вызывает срабатывание вашего кода, который, в свою очередь, выбирается из таблицы package_options. В любой момент у вас могут быть тысячи пользователей, попавших в эту таблицу.

Это может быть проблема, с которой PG может не справиться с параллелизмом, поэтому только тестирование докажет что-либо. Вы должны проверить это, чтобы убедиться в этом, но об этом следует помнить при рассмотрении этого подхода. Я также проверил бы ваш вариант 1 и посмотрел, какой из них работает лучше, чем простой интерфейс для управления и использования. Учитывая, что тесты, необходимые для этого, было бы относительно просто, почему бы не протестировать его, чтобы вы не застряли в дороге с плохим выбором для вашего сценария использования.

Answer 3

Я бы выбрал вариант 1, должно быть достаточно просто написать скрипт, который автоматически сделает это за вас, и вы затем сохраните пакет как можно ближе к исходному определению.