Postgresql пакеты как в oracle

Обновлено: 06.07.2024

Работа между базами данных PostgreSQL Oracle tool-Oracle_fdw

Oracle_fdw - это внешний интерфейс данных PG, который позволяет PostgreSQL легко управлять Oracle между базами данных. Роль Oracle_fdw имеет следующие два момента:

  • PG может добавлять, удалять, изменять и запрашивать таблицы в Oracle в разных базах данных, запрашивать представления Oracle и выполнять запросы соединения между таблицами PG и таблицами / представлениями Oracle, аналогично dblink.
  • Быстро переносите таблицы Oralce в PostgreSQL.
    В этой статье кратко рассказывается об установке и использовании Oracle_fdw.

1.1 Установите Oracle Instant Client

Изофициальный сайт oralceЗагрузите «Basic» и «SDK», если после загрузки файл находится в / opt / oracle.

1.2 Скомпилируйте oracle_fdw

Включить переменные среды пользователя postgres

Скомпилируйте и установите oracle_fdw

Если об ошибке не сообщается, это означает, что установка прошла успешно, а иногда возникает ошибка, заключающаяся в том, что файл заголовка .h не может быть найден, например:

img_e50e15797b9b47c570049e0575bce7f2.jpg

Все это доказывает, что ORACLE_HOME не указан или настроен неправильно, необходимо проверить правильность переменных среды и соответствующих им файлов.

Представитель успешно создан, если вы столкнулись со следующей проблемой:

Файл so отсутствует. Иногда компиляция проходит успешно, но многие файлы все еще отсутствуют. Используйте ldd, чтобы проверить зависимости oracle_fdw.so:

Для этих файлов not found so мы обнаружили, что они существуют в каталоге ORACLE_HOME, как показано ниже:

img_8657a3d4d0941a6096430471996dfd60.jpg

Следовательно, вам необходимо вручную установить мягкое соединение:

Снова создайте oracle_fdw:

Он должен быть успешно создан.

Таким образом, таблица MG_APP.ZWGK_SJJC_FBYJ_GTSJHD в oracle «отображается» на pg и может быть запрошена.

4.1 Ошибка OCIEnvCreate

img_eb48da9e472c475b7d118b64cd327b7a.jpg

1 Проверьте конфигурацию ORACLE_HOME в / etc / profile и ее
export LD_LIBRARY_PATH=$ORACLE_HOME:$LD_LIBRARY_PATH

2 Убедитесь, что в home / postgres / .bashrc также есть:
export LD_LIBRARY_PATH=$ORACLE_HOME:$LD_LIBRARY_PATH

img_553905f3caa77394ac00e7661628e8ab.jpg

3 Проверьте разрешение на выполнение oracle_fdw.so под пользователем postgres:

img_f2033c6b072b095fbf9cd88126cb4553.jpg

Xshell зеленый, если серый, chmod 777 $ PGHOME / lib / oracle_fdw.so

4 Обязательно перезапустите службу pg после завершения всех проверок.

4.2 client host name is not set

img_0ddbff33226dca2f94cce03e49a32b86.jpg

Отредактируйте файл hosts соответствующего сервера:

img_6fdc3cfb9923ab08de91b403f9e20eb9.jpg


Root @ - это имя сервера, поэтому его конфигурация выглядит следующим образом:

img_28cb2841af7a53010315b851408312c3.jpg

Сохраните и выйдите, чтобы решить проблему.

Интеллектуальная рекомендация


[Makefile от более мелких к более глубоким полная запись обучения 4] Переменные и различные методы присвоения

Давайте сегодня узнаем о различных методах присваивания переменных в Makefile! Смысл тяжелой работы, чтобы бедность больше не ограничивать свое воображение! Добавьте QQ, чтобы вместе учиться и обменив.

[Luogu P3147] [BZOJ 4576] [USACO16OPEN]262144

Портал Луогу БЗОЙ Портал Описание заголовка Bessie likes downloading games to play on her cell phone, even though she doesfind the small touch screen rather cumbersome to use with her large hooves. Sh.

В этом разделе рассматриваются различия между языками PostgreSQL PL/pgSQL и Oracle PL/SQL , чтобы помочь разработчикам, переносящим приложения из Oracle ® в PostgreSQL .

PL/pgSQL во многих аспектах похож на PL/SQL . Это блочно-структурированный, императивный язык, в котором все переменные должны объявляться. Присвоения, циклы и условные операторы в обоих языках похожи. Основные отличия, которые необходимо иметь в виду при портировании с PL/SQL в PL/pgSQL , следующие:

Если имя, используемое в SQL-команде, может быть как именем столбца таблицы, так и ссылкой на переменную функции, то PL/SQL считает, что это имя столбца таблицы. Это соответствует поведению PL/pgSQL при plpgsql.variable_conflict = use_column , что не является значением по умолчанию, как описано в Подразделе 41.10.1. В первую очередь, было бы правильно избегать таких двусмысленностей, но если требуется портировать большое количество кода, зависящее от данного поведения, то установка переменной variable_conflict может быть лучшим решением.

В PostgreSQL тело функции должно быть записано в виде строки. Поэтому нужно использовать знак доллара в качестве кавычек или экранировать одиночные кавычки в теле функции. (См. Подраздел 41.11.1.)

Имена типов данных часто требуют корректировки. Например, в Oracle строковые значения часто объявляются с типом varchar2 , не являющимся стандартным типом SQL. В PostgreSQL вместо него нужно использовать varchar или text . Подобным образом, тип number нужно заменять на numeric или другой числовой тип, если найдётся более подходящий.

Для группировки функций вместо пакетов используются схемы.

Так как пакетов нет, нет и пакетных переменных. Это несколько раздражает. Вместо этого можно хранить состояние каждого сеанса во временных таблицах.

Целочисленные циклы FOR с указанием REVERSE работают по-разному. В PL/SQL значение счётчика уменьшается от второго числа к первому, в то время как в PL/pgSQL счётчик уменьшается от первого ко второму. Поэтому при портировании нужно менять местами границы цикла. Это печально, но вряд ли будет изменено. (См. Подраздел 41.6.3.5.)

Циклы FOR по запросам (не курсорам) также работают по-разному. Переменная цикла должна быть объявлена, в то время как в PL/SQL она объявляется неявно. Преимущество в том, что значения переменных доступны и после выхода из цикла.

41.12.1. Примеры портирования

Пример 41.8 показывает, как портировать простую функцию из PL/SQL в PL/pgSQL .

Пример 41.8. Портирование простой функции из PL/SQL в PL/pgSQL

Функция Oracle PL/SQL :

Пройдемся по этой функции и посмотрим различия по сравнению с PL/pgSQL :

Имя типа varchar2 нужно сменить на varchar или text . В примерах данного раздела мы будем использовать varchar , но обычно лучше выбрать text , если не требуется ограничивать длину строк.

Ключевое слово RETURN в прототипе функции (не в теле функции) заменяется на RETURNS в PostgreSQL . Кроме того, IS становится AS , и нужно добавить предложение LANGUAGE , потому что PL/pgSQL — не единственный возможный язык.

В PostgreSQL тело функции является строкой, поэтому нужно использовать кавычки или знаки доллара. Это заменяет завершающий / в подходе Oracle.

Вот как эта функция будет выглядеть после портирования в PostgreSQL :

Пример 41.9 показывает, как портировать функцию, которая создаёт другую функцию, и как обрабатывать проблемы с кавычками.

Пример 41.9. Портирование функции, создающей другую функцию, из PL/SQL в PL/pgSQL

Следующая процедура получает строки из SELECT и строит большую функцию, в целях эффективности возвращающую результат в операторах IF .

В конечном итоге в PostgreSQL эта функция может выглядеть так:

Обратите внимание, что тело функции строится отдельно, с использованием quote_literal для дублирования кавычек. Эта техника необходима, потому что мы не можем безопасно использовать знаки доллара при определении новой функции: мы не знаем наверняка, какие строки будут вставлены из referrer_key.key_string . (Мы предполагаем, что referrer_key.kind всегда имеет значение из списка: host , domain или url , но referrer_key.key_string может быть чем угодно, в частности, может содержать знаки доллара.) На самом деле, в этой функций есть улучшение по сравнению с оригиналом Oracle, потому что не будет генерироваться неправильный код, когда referrer_key.key_string или referrer_key.referrer_type содержат кавычки.

Пример 41.10 показывает, как портировать функцию с выходными параметрами ( OUT ) и манипулирующую строками. В PostgreSQL нет встроенной функции instr , но её можно создать, используя комбинацию других функций. В Подраздел 41.12.3 приведена реализации instr на PL/pgSQL , которая может быть полезна вам при портировании ваших функций.

Пример 41.10. Портирование из PL/SQL в PL/pgSQL процедуры, которая манипулирует строками и содержит OUT параметры

Следующая процедура на языке Oracle PL/SQL разбирает URL и возвращает составляющие его элементы (сервер, путь и запрос).

Вот возможная трансляция в PL/pgSQL :

Эту функцию можно использовать так:

Пример 41.11 показывает, как портировать процедуру, использующую большое количество специфических для Oracle возможностей.

Пример 41.11. Портирование процедуры из PL/SQL в PL/pgSQL

Подобные процедуры легко преобразуются в функции PostgreSQL , возвращающие void . На примере этой процедуры можно научиться следующему:

В PL/pgSQL эту процедуру можно портировать так:

Основное функциональное отличие между этой процедурой и Oracle эквивалента в том, что монопольная блокировка таблицы cs_jobs будет продолжаться до окончания вызывающей транзакции. Кроме того, если впоследствии работа вызывающей программы прервётся (например из-за ошибки), произойдёт откат всех действий, выполненных в этой процедуре.

41.12.2. На что ещё обратить внимание

В этом разделе рассматриваются ещё несколько вещей, на которые нужно обращать внимание при портировании функций из Oracle PL/SQL в PostgreSQL .

41.12.2.1. Неявный откат изменений после возникновения исключения

В PL/pgSQL при перехвате исключения в секции EXCEPTION все изменения в базе данных с начала блока автоматически откатываются. В Oracle это эквивалентно следующему:

При портировании процедуры Oracle, которая использует SAVEPOINT и ROLLBACK TO в таком же стиле, задача простая: достаточно убрать операторы SAVEPOINT и ROLLBACK TO . Если же SAVEPOINT и ROLLBACK TO используются по-другому, то придётся подумать.

41.12.2.2. EXECUTE

PL/pgSQL версия EXECUTE работает аналогично версии в PL/SQL , но нужно помнить об использовании quote_literal и quote_ident , как описано в Подразделе 41.5.4. Без использования этих функций конструкции типа EXECUTE 'SELECT * FROM $1'; будут работать ненадёжно.

41.12.2.3. Оптимизация функций на PL/pgSQL

Для оптимизации исполнения PostgreSQL предоставляет два модификатора при создании функции: « изменчивость » (будет ли функция всегда возвращать тот же результат при тех же аргументах) и « строгость » (возвращает ли функция NULL, если хотя бы один из аргументов NULL). Для получения подробной информации обратитесь к справочной странице CREATE FUNCTION .

При использовании этих атрибутов оптимизации оператор CREATE FUNCTION может выглядеть примерно так:

41.12.3. Приложение

Этот раздел содержит код для совместимых с Oracle функций instr , которые можно использовать для упрощения портирования.

Это руководство призвано помочь вам осуществить миграцию схемы Oracle в Базу данных Azure для PostgreSQL.

Подробные и исчерпывающие инструкции по миграции см. в материалах руководства по миграции.

Предварительные требования

Для переноса схемы Oracle в Базу данных Azure для PostgreSQL необходимо:

  • убедиться в том, что исходная среда поддерживается;
  • скачать последнюю версию ora2pg;
  • иметь в наличии последнюю версию модуля DBD.

Обзор

PostgreSQL — одна из самых продвинутых баз данных с открытым исходным кодом в мире. В этой статье описывается, как использовать бесплатный инструмент ora2pg для переноса базы данных Oracle в PostgreSQL. Ora2pg можно использовать для переноса базы данных Oracle или базы данных MySQL в схему, совместимую с PostgreSQL.

Инструмент ora2pg подключает базу данных Oracle, автоматически сканирует ее и извлекает ее структуру или данные. Затем ora2pg создает скрипты SQL, которые можно загрузить в базу данных PostgreSQL. Ora2pg можно использовать для таких задач, как реконструирование базы данных Oracle, перенос огромной базы данных предприятия или просто репликация некоторых данных Oracle в базу данных PostgreSQL. Этот инструмент прост в использовании и не требует обладания знаниями о базах данных Oracle, кроме способности указать параметры, необходимые для подключения к базе данных Oracle.

Дополнительные сведения об использовании последней версии ora2pg см. в документации по ora2pg.

Типичная архитектура миграции ora2pg

Снимок экрана с архитектурой миграции ora2pg.

После подготовки виртуальной машины и Базы данных Azure для PostgreSQL, понадобятся две конфигурации для обеспечения подключения между ними: Разрешить доступ к службам Azure и Принудительно использовать SSL-соединение.

Колонка Безопасность подключения > Разрешить доступ к службам Azure > ВКЛ

Колонка Безопасность подключения > Параметры SSL > Принудительно использовать SSL-соединение > ОТКЛЮЧЕНО

Рекомендации

Чтобы повысить производительность операций оценки или экспорта на сервере Oracle, выполните сбор статистики:

Экспортируйте данные с помощью команды COPY вместо INSERT .

Избегайте экспорта таблиц с внешними ключами (FK), ограничениями и индексами. Эти элементы замедляют процесс импорта данных в PostgreSQL.

Создайте материализованные представления с помощью предложения без данных. Затем обновите представления.

По возможности используйте уникальные индексы в материализованных представлениях. Эти индексы могут ускорить обновление при использовании синтаксиса REFRESH MATERIALIZED VIEW CONCURRENTLY .

Подготовка к миграции

Убедившись, что исходная среда поддерживается и что выполнены все предварительные требования, вы можете приступать к этапу подготовки к миграции. Чтобы начать работу, сделайте следующее:

  1. Обнаружить: проведите инвентаризацию баз данных, которые необходимо перенести.
  2. Оценить: оцените эти базы данных, чтобы избежать потенциальных ошибок миграции или проблем, препятствующих переносу.
  3. Преобразовать: устраните все обнаруженные проблемы.

Для неоднородных миграций, таких как из Oracle в Базу данных Azure для PostgreSQL, на этом этапе также предполагается, что схемы баз данных-источников совместимы с целевой средой.

Обнаружить

Цель этапа обнаружения — установить существующие источники данных и сведения об используемых функциях. Этот этап поможет вам лучше понять и спланировать миграцию. Этот процесс включает в себя сканирование сети для обнаружения всех экземпляров Oracle в организации, а также их версий и используемых функций.

Скрипты предварительной оценки Майкрософт для Oracle выполняются в базе данных Oracle. Скрипты предварительной оценки запрашивают метаданные Oracle. Скрипты предоставляют следующее:

  • Данные инвентаризации базы данных, включая количество объектов по схеме, типу и состоянию.
  • Приблизительная оценка необработанных данных в каждой схеме на основе статистики.
  • Размер таблиц в каждой схеме.
  • Количество строк кода для каждого пакета, функции, процедуры и т. д.

Скачайте связанные сценарии из GitHub.

Оценка

После проведения инвентаризации баз данных Oracle вы получите представление о их размере и возможных проблемах. Следующим этапом будет выполнение оценки.

Оценить затраты на миграцию из Oracle в PostgreSQL непросто. Чтобы оценить затраты на миграцию, ora2pg проверяет все объекты базы данных, функции и хранимые процедуры для объектов, а также код PL/SQL, который не может быть преобразован автоматически.

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

Чтобы активировать режим анализа и создания отчета, используйте экспортированный тип SHOW_REPORT , как показано в следующей команде:

Средство ora2pg может преобразовать код SQL и PL/SQL из синтаксиса Oracle в PostgreSQL. Итак, после анализа базы данных ora2pg может оценить проблемы с кодом и время, необходимое для миграции всей базы данных.

Чтобы оценить затраты на миграцию в человеко-днях, ora2pg позволяет использовать директиву конфигурации с именем ESTIMATE_COST . Эту директиву также можно включить в командной строке:

Единица миграции по умолчанию составляет около пяти минут для эксперта PostgreSQL. Если перенос выполняется впервые, можно увеличить единицу миграции по умолчанию с помощью директивы конфигурации COST_UNIT_VALUE или параметра командной строки --cost_unit_value .

В последней строке отчета отображается общий предполагаемый код миграции в человеко-днях. Оценка учитывает количество расчетных единиц миграции для каждого объекта.

В следующем примере кода показаны некоторые варианты оценки:

  • Оценка таблиц
  • Оценка столбцов
  • Оценка схемы, использующая единицу затрат по умолчанию, равную 5 минутам
  • Оценка схемы, использующая единицу затрат, равную 10 минутам

Ниже приведены выходные данные уровня миграции B-5 по оценке схемы.

A — миграция, которую можно выполнить автоматически

B — миграция с переписыванием кода и затратами в человеко-днях до 5 дней

C — миграция с переписыванием кода и затратами в человеко-днях больше 5 дней

1 = Тривиальный: нет хранимых функций и триггеров

2 = Простой: нет хранимых функций, за исключением триггеров; без перезаписи вручную

3 = Обычный: есть хранимые функции и (или) триггеры; без перезаписи вручную

4 = Ручной: нет хранимых функций, но есть триггеры или представления с перезаписью кода

5 = Сложный: есть хранимые функции и (или) триггеры с перезаписью кода

Оценка включает в себя следующее:

Буква (A или B), указывающая, нуждается ли миграция в ручной перезаписи.

Число от 1 до 5, указывающее на техническую сложность.

Другой параметр, -human_days_limit , указывает ограничение в человеко-днях. Здесь задайте уровень миграции C, чтобы указать, что для миграции требуется большой объем работы, полное управление проектом и поддержка миграции. По умолчанию — 10 человеко-дней. Можно использовать директиву конфигурации HUMAN_DAYS_LIMIT для постоянного изменения значения по умолчанию.

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

Convert

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

На этом этапе миграции код Oracle и скрипты DDL конвертируются или преобразуются в PostgreSQL. Инструмент ora2pg автоматически экспортирует объекты Oracle в формате PostgreSQL. Некоторые созданные объекты не могут быть скомпилированы в базе данных PostgreSQL без внесения изменений вручную.

Чтобы понять, какие элементы требуют вмешательства вручную, сначала скомпилируйте файлы, созданные ora2pg, в базе данных PostgreSQL. Проверьте журнал и внесите необходимые изменения, чтобы обеспечить совместимость структуры схемы с синтаксисом PostgreSQL.

Создание шаблона миграции

Мы рекомендуем использовать шаблон миграции, предоставляемый ora2pg. При использовании параметров --project_base и --init_project ora2pg создает шаблон проекта с деревом работ, файлом конфигурации и скриптом для экспорта всех объектов из базы данных Oracle. Дополнительные сведения см. в документации по ora2pg.

Используйте следующую команду:

Ниже приведен пример выходных данных:

Каталог sources/ содержит код Oracle. Каталог schema/ содержит код, перенесенный в PostgreSQL. Каталог reports/ содержит отчеты в формате HTML и оценку затрат на миграцию.

После создания структуры проекта создается универсальный файл конфигурации. Определите подключение к базе данных Oracle и соответствующие параметры конфигурации в файле конфигурации. Дополнительные сведения о файле конфигурации см. в документации по ora2pg.

Экспорт объектов Oracle

Затем экспортируйте объекты Oracle как объекты PostgreSQL, запустив файл export_schema.sh.

Запустите следующую команду вручную.

Извлеките данные, используя следующую команду.

Компиляция файлов

Наконец, скомпилируйте все файлы на сервере базы данных Azure для PostgreSQL. Можно выбрать загрузку созданных вручную файлов DDL или использовать второй скрипт import_all.sh для интерактивного импорта этих файлов.

Ниже приведена команда импорта данных.

Во время компиляции файлов проверяйте журналы и исправляйте синтаксис, который ora2pg не смог преобразовать самостоятельно.

Миграция

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

Миграция схемы и данных

После внесения необходимых исправлений стабильная сборка базы данных будет готова к развертыванию. Выполните команды импорта psql , указывающие на файлы с измененным кодом. Эта задача компилирует объекты базы данных в базу данных PostgreSQL и импортирует данные.

На этом этапе можно реализовать уровень параллелизма при импорте данных.

Синхронизация данных и переход

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

На этапе синхронизации данных убедитесь, что все изменения в источнике фиксируются и применяются к целевому объекту практически в реальном времени. Убедившись, что все изменения применены, можно выполнить переход из источника в целевую среду.

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

В таблице исходных данных сначала перенесите все исторические данные. Ниже приведен пример:

Вы можете запросить изменения с момента первоначальной миграции, выполнив следующую команду:

В этом случае рекомендуется повысить уровень проверки, сверяя четность данных с обеих сторон — в источнике и целевом объекте.

После миграции

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

Исправление приложений

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

После переноса данных в целевой объект запустите тесты для баз данных, чтобы убедиться в правильной работе этих приложений с целевым объектом. Убедитесь, что исходный и целевой объекты были перенесены надлежащим образом, запустив ручные скрипты проверки данных в исходной базе данных Oracle и целевой базе данных PostgreSQL.

Если исходная и целевая базы данных имеют сетевой путь, для проверки данных предпочтительно использовать ora2pg. С помощью действия TEST можно убедиться, что все объекты базы данных Oracle были созданы в PostgreSQL.

Выполните следующую команду:

Оптимизация

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

Ресурсы, посвященные миграции

Дополнительные сведения об этом сценарии миграции можно получить в приведенных ниже ресурсах. Они содержат вспомогательные материалы по реализации реальных проектов миграции.

Ресурс Описание
Руководство по миграции из Oracle в Базу данных Azure для PostgreSQL Этот документ поможет архитекторам, консультантам, администраторам баз данных и связанным ролям быстро переносить рабочие нагрузки из Oracle в Базу данных Azure для PostgreSQL с помощью ora2pg.
Решения по миграции из Oracle в Базу данных Azure для PostgreSQL Этот документ поможет архитекторам, консультантам, администраторам баз данных и связанным ролям быстро устранять или обходить проблемы при переносите рабочих нагрузок из Oracle в Базу данных Azure для PostgreSQL.
Инструкции по установке ora2pg в Windows или Linux Этот документ содержит краткое руководство по установке для миграции схемы и данных из Oracle в Базу данных Azure для PostgreSQL с помощью ora2pg в Windows или Linux. Дополнительные сведения см. в документации по ora2pg.

Эти ресурсы разработали специалисты по разработке данных SQL. Основная задача этой команды — включить и ускорить комплексную модернизацию проектов миграции платформы данных на платформу данных Microsoft Azure.

Дополнительная поддержка

Чтобы получить справку по миграции, не связанную с инструментарием ora2pg, отправьте письмо по следующему адресу: @AskБаза данных Azure для PostgreSQL.

Дальнейшие действия

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


Oracle является одним из крупнейших поставщиков RDBMS (системы управления реляционными базами данных). База данных Oracle используется многими компаниями в ИТ-индустрии для обработки транзакций, бизнес-аналитики, приложений бизнес-аналитики. PostgreSQL - это система управления объектно-реляционными базами данных с открытым исходным кодом, разработанная командой добровольцев со всего мира, написанных на языке Си. Пользователи могут расширять PostgreSQL, изменяя существующие функции, добавляя новые функции и распространяя их свободно с открытым исходным кодом.

Что такое Oracle?

Oracle является одним из крупнейших поставщиков RDBMS (системы управления реляционными базами данных) на рынке информационных технологий. Он называется базой данных Oracle, базой данных Oracle или Oracle, поставляемой на рынок Oracle. База данных Oracle разработана в 1977 году Лоуренсом Эллисоном, которая построена вокруг реляционной базы данных, в которой пользователи могут получать доступ к данным через приложение или язык запросов, называемый SQL (структурированный язык запросов). Корпорация Oracle впервые выпустила на рынок СУБД oracle в 1979 году. База данных Oracle доступна в различных редакциях, таких как корпоративная, стандартная, экспресс-версия и oracle lite. База данных Oracle работает на основных платформах, таких как Windows, UNIX, Linux и MacOS. Крупнейшим конкурентом для базы данных Oracle является Microsoft SQL Server.

Что такое PostgreSQL?

PostgreSQL не поддерживал SQL до 1994 года - для запроса данных использовался язык QUEL. Позже была добавлена ​​поддержка SQL. PostgreSQL становится открытым исходным кодом в 1996 году. PostgreSQL поддерживает все функции RDBMS с добавлением других функций, которые недоступны в RDBMS, таких как представления, хранимые процедуры, индексы и триггеры, в дополнение к функциям первичного ключа, внешнего ключа и атомарности. Он работает на основных платформах, таких как UNIX, MacOS, Windows, Linux и т. Д. Он поддерживает видео, текст, аудио, изображения, программные интерфейсы для различных языков, таких как C / C ++, Java, Python, Perl и т. Д., И открытую базу данных. подключение.

Сравнение лицом к лицу между Oracle и PostgreSQL (инфографика)


Ниже приведено 7 главных отличий производительности Oracle от PostgreSQL.

Ключевые различия между Oracle и PostgreSQL

Oracle и PostgreSQL Performance являются популярным выбором на рынке; Давайте обсудим некоторые основные различия между Oracle и PostgreSQL:

Сравнительная таблица Oracle и PostgreSQL

Основное сравнение производительности Oracle и PostgreSQL обсуждается ниже:

оракул

PostgreSQL

Вывод - Oracle против PostgreSQL

Наконец, это обзор сравнения Oracle и PostgreSQL в различных аспектах. Я надеюсь, что вы будете лучше понимать эти темы после прочтения этой статьи о Oracle и PostgreSQL. Мы видели разницу между Oracle и PostgreSQL, и я могу сказать, что PostgreSQL во многих случаях более мощный, чем Oracle, с открытым исходным кодом, совместимостью с другими RDBMS и простотой использования с большим сообществом разработчиков. Мы можем выбрать базу данных на основе конкретного проекта. PostgreSQL используется во многих отраслях, таких как приложения для больниц, генетика пациентов, приложения B2B и т. Д.

Рекомендуемая статья

Это было руководство к основным различиям между Oracle и PostgreSQL. Здесь мы также обсудим ключевые отличия Oracle от PostgreSQL с помощью инфографики и таблицы сравнения. Вы также можете взглянуть на следующие статьи -

Читайте также: