Como usar o SQL em um aplicativo
Para usar o SQL em um aplicativo, você tem que combiná-lo com um processual
Menu
Felizmente, os pontos fortes do SQL tendem a compensar as fraquezas de linguagens procedurais, e os pontos fortes das linguagens procedurais são nas áreas onde SQL é fraca. Ao combinar os dois, você pode construir aplicações poderosas com uma ampla gama de capacidades.
Recentemente, orientada a objetos desenvolvimento rápido de aplicações (RAD) ferramentas, como o Visual Studio da Microsoft e do ambiente Eclipse open-source, têm aparecido, que incorporam o código SQL em aplicativos desenvolvidos por manipular objetos na tela em vez de escrever código de procedimento.
Mantenha-se atento para o asterisco
O asterisco (*) Serve como um substituto abreviada para # 147 todas as colunas na tabela. # 148- Se a tabela tem várias colunas, o asterisco pode salvar um monte de digitação. No entanto, usando o asterisco dessa forma é problemático quando você usa o SQL em um programa aplicativo. Depois que seu aplicativo é escrito, você ou outra pessoa pode adicionar novas colunas a uma tabela ou apagar as antigas.
Se o fizer, muda o significado de # 147 todas as colunas. # 148- Quando seu aplicativo especifica # 147 todas as colunas # 148- com um asterisco, pode recuperar diferentes daqueles que pensa que está ficando colunas.
Tal mudança para uma tabela não afeta os programas existentes até que eles tem que ser recompilados para corrigir um erro ou fazer alguma mudança, talvez meses após a alteração foi feita. Em seguida, o efeito da * wildcard se expande para incluir todas as colunas agora circulante. Esta alteração pode causar a falha do aplicativo de uma forma relacionada com a correção de erros (ou outras alterações), criando a sua própria depuração pessoal pesadelo.
Para ser seguro, especificar todos os nomes de coluna explicitamente em um aplicativo em vez de usar o curinga asterisco.
pontos fortes e fracos SQL
Se a informação importante é enterrado em algum lugar em uma única mesa ou banco de dados multitable, SQL dá-lhe as ferramentas necessárias para recuperá-lo. Você não precisa saber a ordem de linhas ou colunas da tabela porque o SQL não lida com linhas ou colunas individualmente. As instalações de processamento de transações SQL garantir que suas operações de banco de dados não são afetados por quaisquer outros usuários que podem ser simultaneamente acessando a mesma tabela que você é.
A grande fraqueza do SQL é a sua interface de usuário rudimentar. Ele não tem nenhuma disposição para a formatação de telas ou relatórios. Ele aceita linhas de comandos do teclado e envia valores recuperados para a tela do monitor, uma linha de cada vez.
Às vezes uma força em um contexto é uma fraqueza em outro. Uma força de SQL é que ele pode operar sobre uma tabela inteira de uma vez. Se a tabela tem uma linha, uma centena de linhas, ou cem mil linhas, um único SELECIONAR declaração pode extrair os dados que deseja.
SQL não pode facilmente operar em uma linha de cada vez, no entanto - e às vezes você não quer lidar com cada linha individualmente. Nesses casos, você pode usar o recurso de cursor do SQL ou você pode usar uma linguagem de acolhimento processual.
pontos fortes e fracos de linguagens procedurais
As linguagens procedurais são projetados para operações de uma linha-em-um-tempo, que dão o desenvolvedor do aplicativo controle preciso sobre a forma como a tabela é processada. Este controle detalhado é uma grande força de linguagens procedurais. Mas uma fraqueza correspondente é que o desenvolvedor do aplicativo deve ter conhecimento detalhado sobre como os dados são armazenados nas tabelas de banco de dados. A ordem das colunas e linhas do banco de dados é significativo e deve ser levado em conta.
Devido à natureza passo-a-passo de linguagens procedurais, eles têm a flexibilidade para produzir telas amigáveis para entrada de dados e visualização. Você também pode produzir relatórios impressos sofisticados com qualquer layout desejado.
Problemas em combinar SQL com uma linguagem procedural
Não faz sentido tentar combinar SQL e linguagens procedurais, de tal maneira que você pode se beneficiar de suas forças mútuas e não ser penalizado por suas fraquezas combinados. Tão valioso como tal combinação pode ser, você tem que superar alguns desafios antes de poder atingir esse casamento perfeito de uma forma prática.
Contrastando modos de operação
Um grande problema em combinar SQL com uma linguagem processual é que o SQL opera em mesas de um conjunto de cada vez, enquanto que as linguagens procedurais trabalhar com eles uma linha de cada vez. Às vezes, esta questão não é um grande negócio. Você pode separar operações de conjunto de operações de linha, fazendo cada um com a ferramenta apropriada.
Mas se você quiser procurar uma mesa para registros de reuniões determinadas condições e executar operações diferentes nos registros, dependendo se cumprem as condições, você pode ter um problema. Tal processo requer tanto o poder de recuperação de SQL ea capacidade de ramificação de uma linguagem procedural.
SQL embutido dá-lhe esta combinação de capacidades. Você pode simplesmente embutir instruções SQL em locais estratégicos dentro de um programa que você tenha escrito em uma linguagem procedural convencional.
incompatibilidades de tipos de dados
Outro obstáculo para a integração harmoniosa de SQL com qualquer linguagem processual é que os tipos de dados do SQL diferem dos tipos de dados de todas as principais línguas processuais. Esta circunstância não deveria ser surpreendente, porque os tipos de dados definidos para qualquer linguagem procedural são diferentes dos tipos para as outras línguas processuais.
Você pode olhar do alto e baixo, mas você não vai encontrar nenhuma padronização dos tipos de dados em vários idiomas. Em SQL libera antes do SQL-92, do tipo de dados incompatibilidade era uma grande preocupação. No SQL-92 (e também em versões subsequentes do padrão SQL), o FUNDIDA declaração soluciona o problema.