Я играю с PLV8 для записи триггера и хранимых процедур для PostgreSQL. До сих пор я не вижу недостатков по сравнению с PLPGSQL. Особенно, если работать с JSON кажется даже более умным, чем PLPGSQL. Известны ли недостатки или ограничения при использовании PLV8? Может ли PLV8 быть полной заменой PLPGSQL? Было бы здорово, если бы кто-то мог поделиться своим опытом по этому поводу.plv8 недостатки или ограничения?
ответ
Преимущества и недостатки PLV8 такие же, как преимущества и недостатки PLPerl, PLPython и других языков PL.
- Он не интегрирован с движком PostgreSQL - результат обработки SQL-запросов может быть медленнее. PLpgSQL полностью интегрирован в механизм PostgreSQL.
- SQL не интегрирован в язык - невозможно выполнить статический анализ встроенного SQL. Это возможно с PLpgSQL - см. Plpgsql_check.
- Может делать более дорогие математические вычисления, манипуляции со строками и массивами обычно быстрее, чем в PLpgSQL.
- Может использовать библиотеки, разработанные для языков - Perl - CPAN, ...
- JavaScript, Perl, Python - это общие языки - поэтому любые общие задачи реализованы там хорошо.
- PLpgSQL - зрелый язык, предназначенный для манипулирования данными в среде базы данных. Практически все, что нужно разработчикам для работы с данными, есть. Итерация по результату, взятие данных из базы данных требует менее читаемого кода.
PLpgSQL - идеальный язык для обработки данных с использованием языка SQL. Другие PL лучше для чего-либо еще - IO, Network, специального форматирования, медленных числовых вычислений, ...
Указанный вид анализа - это то, о чем я не знал, спасибо Павлу. О производительности. Я несколько красных статей, и у меня сложилось впечатление, что в «нормальных» случаях (например, типичных порталах электронной коммерции) есть только очень небольшие различия в производительности. Но, конечно, есть особые случаи. Итак, еще раз спасибо! – Rainer
Производительность - зависит - размер базы данных, сложность запроса, размер возвращаемого набора результатов, ... –
Немного поздно, но вы не можете убить запрос на текущий скрипт plv8, единственный способ перезапустить весь сервер postgresql. Это огромный недостаток, и наша команда думает о переносе на PLpgPython.
Единственный (очень маленький) недостаток, который я вижу: вам явно нужно установить его для каждой создаваемой вами базы данных. PL/pgSQL всегда доступен по умолчанию. Но только ** вы ** можете решить, является ли это полной заменой или нет: потому что это полностью зависит от требований, которые вы предъявляете к языку. –
спасибо. Я спрашиваю, потому что я хочу знать, есть ли проблемы, о которых я сейчас не думаю. Если я решаю сегодня использовать PLV8 для нового проекта, и через 3 месяца я должен узнать, что ограничения будут плохими. – Rainer
'plpgsql' использует собственные типы данных SQL, преимущество в простоте использования, которое не имеет других PL. Если вы планируете использовать сложные типы данных, такие как 'hstore' или' ltree', вам придется иметь дело с их текстовым представлением в plv8. Но он поддерживает массивы, составные типы, setof, ... который уже довольно хорош. –