Outros idiomas que não o SQL no postgres

Question

Eu estive usando PostgreSQL um pouco ultimamente, e uma das coisas que eu acho que é legal é que você pode usar outros idiomas que não o SQL para a criação de scripts e de funções de outros enfeites.Mas quando este é realmente útil?

Por exemplo, a documentação diz que o principal uso de PL/Perl, é que é muito bom em manipulação de texto.Mas não é que mais de algo que deve ser programado para o aplicativo?

Em segundo lugar, não há qualquer razão válida para o uso de um não idioma?Parece que ele, de forma que qualquer usuário pode executar qualquer operação seria uma má ideia em um sistema de produção.

PS.Pontos de bônus se alguém pode fazer PL/LOLCODE parecem úteis.

Answer 1

"não é que [a manipulação de texto] mais de algo que deve ser programado para o aplicativo?"

Geralmente, sim.Geralmente aceites "três camadas"design de aplicativos de bancos de dados diz que sua lógica deve ser na camada intermediária, entre o cliente e o banco de dados.No entanto, às vezes você precisa de um pouco de lógica em um disparador ou precisa índice em uma função, exigindo que o código ser colocados no banco de dados.Nesse caso, todos os habituais "que linguagem devo usar?" perguntas surgem.

Se você só precisa de um pouco de lógica, o mais portáteis-linguagem provavelmente deve ser usado (pl/pgSQL).Se você precisa fazer sérios de programação, você pode ser melhor fora de usar um mais expressivos da língua (talvez pl/ruby).Este será sempre um julgamento.

"há qualquer razão válida para o uso de um não idioma?"

Como acima, sim.Novamente, colocando acesso direto a arquivos (por exemplo) em sua camada intermediária é melhor quando possível, mas se você precisa de fogo as coisas com base em gatilhos (que podem precisar de acesso a dados não disponíveis diretamente para sua camada intermediária), então você precisa não confiáveis idiomas.Não é o ideal, e deve ser evitada.E você definitivamente precisa para proteger o acesso a ele.

Answer 2

@Mike:esse tipo de pensamento faz-me nervoso.Eu já ouvi muitas vezes "este deve ser infinitamente portátil", mas quando a pergunta é feita:você realmente prever que não haverá qualquer portar?a resposta é:não.

Aderindo ao menor denominador comum pode realmente afetar o desempenho, assim como a introdução de camadas de abstração (ORM, PDO do PHP, etc.).Minha opinião é:

• Avaliar de forma realista, se é necessário o apoio de vários RDBMS do.Por exemplo, se estiver a escrever uma aplicação web open source, as chances são de que você precisa para suporte a MySQL e PostgreSQL pelo menos (se não MSSQL e Oracle)
• Após a avaliação, fazer o máximo de plataforma em que você decidiu sobre

E BTW:você está misturando relacional com a não-relação de bancos de dados (CouchDB é não um RDBMS comparável com o Oracle, por exemplo), ainda exemplificando, a ponto de que a percepção da necessidade de portabilidade é muitas vezes grandemente superestimado.

Answer 3

Estes dias, qualquer "único" ou "legal" funcionalidade de um SGBD me deixa extremamente nervoso.Eu sair de uma erupção de pele e ter que parar de trabalhar até que a coceira desaparece.

Eu só gosto de ser trancada em uma plataforma desnecessariamente.Suponha que você criar uma grande parte de seu sistema em PL/Perl dentro do banco de dados.Ou em C# dentro do SQL Server, ou PL/SQL no Oracle, há uma abundância de exemplos*.

Agora de repente descobre que sua plataforma escolhida não escala.Ou não é rápido o suficiente.Ou algo assim.Pior, há um novo garoto sobre o bloco de banco de dados (algo como MonetDB, CouchDB, Cache, digo, mas muito mais frio) que iria resolver todos os seus problemas (mesmo se o seu único problema, como o meu, está tendo uma chata databse de plataforma).E você não pode alternar para ele sem recodificação de metade da sua aplicação.

(*É verdade que os produtos pagos são em alguma medida, buscando bloquear você por persuadi-lo a usar seus recursos exclusivos, o que não é uma acusação que pode diretamente ser expressas em relação ao livre fornecedores, mas o efeito é o mesmo).

Para que um discurso retórico sobre a primeira parte da pergunta.Coração sentiu, no entanto.

não há qualquer razão válida para o uso de um não confiáveis idioma?Parece que fazendo com que qualquer usuário pode executar qualquer operação seria uma má ideia

Meu deus, sim, é verdade!Uma espécie de "Perl ataque de injeção"?Quase vale a pena fazê-lo apenas para ver o que acontece, eu teria pensado.

Por motivos filosóficos descrito acima, eu acho que eu vou passar em PL/LOLCODE desafio.Apesar de que eu estava um pouco surpreso ao descobrir que era um link para algo existente.

Answer 4

Do meu ponto de vista, eu acho que a resposta for 'depende'.

Há um argumento de que a manipulação de dados pertence a camada de banco de dados, de modo que a lógica de negócios não precisa ser excessivamente preocupados sobre como a manipulação acontece, ele simplesmente sabe que ele tem.

Outra razão muito boa para processar os dados na base de dados de camada é se o volume de dados a serem processados significa que a largura de banda da rede vai se tornar um problema.Uma vez eu tinha para categorizar grandes quantidades de dados.Processamento na camada de aplicação foi severamente restringida pelo tempo necessário para a transferência de todos os dados através da rede para o processamento.

Escrevi, então, uma binning algoritmo em PL/pgSQL e ele trabalhou muito mais rápido.

Sobre não confiáveis línguas, eu ouvi um podcast de Josh Berkus (uma postgres advogado) que discutiram um aplicativo do postgresql que trouxe de dados do MySQL como parte de seu tratamento, de modo que a comunicação foi tratada pelo servidor postgres.Não me lembro de todos os detalhes, eu acho que foi no FIO dental podcast Semanal o que é uma interessante discussão sobre a história do PostGRESQL e algumas das questões postas.

Answer 5

Não confiável versões das línguas processuais permitir o acesso de e/S no sistema.Isto pode vir a calhar se você precisa de um gatilho ou algo enviar um e-mail ou conectar-se a um servidor de soquete para enviar uma notificação de pop-up.Há toneladas de usos para esse tipo de coisa, e por causa do postgresql níveis de isolamento de você latas segura de fazer coisas como esta.Você pode colocar pontos de controle na função de então, se a transação falhar o e-mail ou o que não vai sair.A coisa boa sobre isso é que ele remove a lógica do cliente e coloca-lo no servidor.

Answer 6

Eu acho que a maioria dos idiomas adicionais são oferecidos para que se desenvolvem em que a língua em uma base regular, você pode se sentir confortável a escrever db funções, triggers, etc.A utilidade destes recursos é fornecer um controle sobre os dados como próximo possível de dados.

Answer 7

Um exemplo útil de um procedimento armazenado recentemente escrevi um idioma que não teria sido possível em pl/sql é uma versão de 'df' o que permitiu a tabela de SQL geradores de escolher uma tablespace com mais espaço livre disponível em tempo de execução.

Eu usei plperlu, e era relativamente simples, apesar de que eu tinha que ser cuidadoso com os dados de digitação.