Boa noite,
Existe uma substituição orientada a objetos para PL/SQL, permitindo que os procedimentos do lado do servidor sejam escritos [e então chamados de lado do cliente ou servidor]?
(para MySQL, PostgreSQL, Oracle ou etc.)
Boa noite,
Existe uma substituição orientada a objetos para PL/SQL, permitindo que os procedimentos do lado do servidor sejam escritos [e então chamados de lado do cliente ou servidor]?
(para MySQL, PostgreSQL, Oracle ou etc.)
O Oracle possui Java do lado do servidor, mas gostaria de advertir que não é um substituto para PL/SQL. Não há linguagem melhor do que PL/SQL para manipular dados armazenados no banco de dados - Java pode ser apropriado para lógica de negócios com uso intensivo de computação.
Para postgres ,
Mas acho que é justo dizer que o PL/pgSQL é o mais maduro e completo em recursos (e, você pode se arrepender de saber, muito semelhante ao PL/SQL).
Eu não sei muito sobre os procedimentos armazenados do MySQL, mas aqui está um link para os documentos
Sprocs incorporados em um DBMS
Acho que, para os propósitos da sua pergunta, a resposta provavelmente está entre 'não' e 'depende'.
A maioria das plataformas relacionais de DBMS oferece suporte a procedimentos armazenados em um dialeto derivado do SQL ou em uma linguagem procedural com recursos SQL incorporados. PL/SQL é um exemplo da última classe de linguagens.
Escrever consultas em linguagens arbitrárias não é realmente uma opção, pois eles ainda precisam interagir com o otimizador de consultas, portanto, só podem expressar semântica compatível com sua arquitetura. Até mesmo dialetos SQL 'procedimentais' como o T-SQL na verdade emitem várias consultas ao otimizador. O SQL sempre será limitado dessa maneira devido ao acoplamento rígido com a arquitetura do otimizador de consulta.
Muitas plataformas DBMS oferecem suporte a linguagens alternativas para procedimentos armazenados, como JVM no Oracle, integração CLR no SQL Server e várias linguagens incorporadas no PostgreSQL. Isso permite escrever código processual, oferecer suporte a conexões locais rápidas com o DBMS e (em alguns casos) integrar com APIs no gerenciador de banco de dados. Essas APIs permitem que você escreva funções de agregação personalizadas e outras extensões.
No entanto, há bons motivos para não usar isso para código de aplicativo não SQL, a menos que seja realmente necessário, especialmente no caso do Oracle. Três razões principais são:
Muitas vezes, é muito difícil depurar o código quando ele é incorporado ao DBMS dessa maneira.
Não há APIs padrão para esse tipo de código. É altamente não portátil e fortemente acoplado ao DBMS - você nem mesmo tem as mesmas opções de idioma entre as plataformas. Você teria que escrever e manter um subsistema separado para cada plataforma de DBMS que pretende suportar.
Você está pagando o licenciamento do DBMS pela capacidade da CPU que está usando para executar o código. No caso da Oracle, a licença do DBMS pode ser muito mais cara do que o hardware em que está sendo executada.
Geralmente, só é sensato usar código embutido no SGBD para aplicações onde é estritamente necessário.
Uma alternativa: plataformas OODBMS
Algumas plataformas OODBMS, como Gemstone/S, são projetadas para suportar uma linguagem OO estreitamente acoplada e o sistema deve ser executado dessa forma. No entanto, no caso do Gemstone/S, o sistema está fortemente acoplado a um conjunto limitado de idiomas, principalmente Smalltalk.
No entanto, a VM Gemstone/S é boa o suficiente para que alguém até mesmo portou o ruby para rodar nela com um projeto chamado maglev. . Isso pode aproximá-lo do que você deseja, mas exige que você mude para uma plataforma específica.