10 erros comuns de SQL

Enfrentá-lo - ninguém estuda SQL para o divertimento dele. Você usa SQL para construir aplicações de banco de dados, mas antes que você possa construir um, você precisa de um banco de dados. Infelizmente, muitos projectos dão errado antes da primeira linha da aplicação está codificada. Se você não obter o direito de definição de banco de dados, o aplicativo está condenado. Aqui estão dez erros comuns de criação de banco de dados que você deve estar à procura de.

Não suponha que seus clientes sabem o que eles precisam

Geralmente, os clientes chamá-lo para projetar um sistema de banco de dados quando eles têm um problema em obter as informações que precisam, porque os seus métodos atuais não estão funcionando. Os clientes muitas vezes acreditam que eles identificaram o problema e sua solução. Eles imaginam que tudo que eles precisam fazer é dizer você o que fazer.

Errado. A maioria dos usuários não possuem o conhecimento ou habilidades necessárias para identificar com precisão o problema, então eles têm pouca chance de determinar a melhor solução.

Seu trabalho é convencer diplomaticamente seu cliente que você é um especialista em análise de sistemas e design e que você deve fazer uma análise adequada para descobrir a causa real do problema.

Não ignore o escopo do projeto

Seu cliente lhe diz que ele ou ela espera do novo aplicativo no início do projeto de desenvolvimento. Infelizmente, o cliente quase sempre se esquece de dizer-lhe algo - normalmente várias coisas. Ao longo do trabalho, estas novas exigências surgem e são tacked para o projeto.

Se você está sendo pago com base em projeto, em vez de numa base horária, este crescimento no escopo pode mudar o que já foi um projeto lucrativo em um perdedor. Certifique-se de que tudo o que você é obrigado a entregar é especificado por escrito, antes de iniciar o projeto.

Não considerar somente fatores técnicos

Questões de máximos de custo, disponibilidade de recursos, condições de programação e organização política pode ter um efeito importante sobre o projeto. Esses problemas podem transformar um projeto que é viável em um pesadelo. Certifique-se de que você compreenda todos os fatores não técnicos relevantes antes de iniciar qualquer projeto de desenvolvimento.

Não evite feedback do cliente

Sua primeira inclinação deve ser a ouvir os gestores que você contratar. Afinal de contas, os usuários certeza que Parreira não pagar a sua taxa. Por outro lado, pode haver uma boa razão para ignorar os administradores, também. Eles geralmente não têm um indício sobre o que os usuários realmente precisam. Espere um minuto!

Não ignore todos ou assuma que você sabe mais do que um gerente ou usuário sobre como um banco de dados deve funcionar. funcionários de entrada de dados normalmente não têm muita influência organizacional, e muitos gestores têm apenas uma compreensão fraca de alguns aspectos do trabalho que os funcionários de entrada de dados fazer. Mas isolar-se a partir de qualquer grupo é quase certo que resultará em um sistema que resolve um problema que ninguém tem.

Você não pode sempre usar o seu ambiente de desenvolvimento favorito

Você provavelmente já passou meses ou mesmo anos se tornar proficientes no uso de um determinado ambiente de desenvolvimento DBMS ou aplicativo. Mas seu ambiente favorito - não importa o que é - tem pontos fortes e fracos.

Então ao invés de kludge juntos algo que não é realmente a melhor solução, morder a bala. Você tem duas opções: ou subir a curva de aprendizagem de um instrumento mais adequado e, em seguida, usá-lo, ou francamente dizer a seus clientes que seu trabalho seria melhor ser feito com uma ferramenta que você não é um especialista em usar.

Em seguida, sugerem que o cliente contratar alguém que pode ser produtiva com essa ferramenta imediatamente. conduta profissional deste tipo acumula respeito dos seus clientes. (Infelizmente, se você trabalha para uma empresa, em vez de por si mesmo, que a conduta também pode levá-lo demitidos ou despedidos.)

Não utilize exclusivamente sua arquitetura favorita sistema

Ninguém pode ser um perito em tudo. sistemas de gerenciamento de banco de dados que trabalham em um ambiente de teleprocessamento são diferentes do que os sistemas que funcionam em cliente / servidor, compartilhamento de recursos, baseado na web, ou em ambientes de banco de dados distribuídos. Escolha a melhor arquitetura de qualquer maneira, mesmo que isso signifique passar no trabalho. Não obtendo o trabalho é melhor do que começá-lo e produzir um sistema que não serve as necessidades do cliente.

Não criar tabelas do banco de isolamento

Se você se identifica incorretamente objetos de dados e seus relacionamentos uns com os outros, suas tabelas de banco de dados são susceptíveis de introduzir erros nos dados e destruir a validade de quaisquer resultados. Para projetar um banco de dados de som, você deve considerar a organização geral dos objetos de dados e cuidadosamente determinar como eles se relacionam entre si. Você deve determinar o que é apropriado, considerando o presente de seu cliente e as necessidades projetadas.

Não negligencie a análise do projeto

Mesmo o melhor designer e desenvolvedor pode perder pontos importantes que são evidentes para alguém olhando para a situação de uma perspectiva diferente. Apresentando o seu trabalho antes de uma revisão de projeto formal pode torná-lo mais disciplinado em seu trabalho. Tem uma avaliação profissional competente seu projeto antes de iniciar o desenvolvimento. Você deve ter um designer de banco de dados verificá-lo mais, mas você pode querer mostrá-lo para o cliente, também.

Não pule testes beta

Mesmo se você testá-lo em todos os sentidos que você pode pensar, a aplicação é certo para conter modos de falha que você não descobrir. O teste beta significa dar o aplicativo para as pessoas que não sabem como ele foi projetado.

Eles são propensos a ter problemas que você nunca encontrou, porque você sabe muito sobre o aplicativo. Você pode então corrigir os erros ou deficiências de desempenho que outros acham antes de o produto entrar oficialmente em uso.

Não se esqueça de documentar o seu processo

Se você acha que a sua aplicação é tão perfeito que nunca precisa ser olhado, ainda mais uma vez, pense novamente. A única coisa que você pode ter certeza absoluta de neste mundo é a mudança. Conte com isso. Seis meses a partir de agora, você não vai se lembrar por que você desenhou as coisas da maneira que você fez, a menos que você cuidadosamente documentar o que você fez e por que você fez isso dessa maneira.

Over-documentar o seu trabalho. Coloque em mais detalhe do que você acha que é razoável. Ele vai pagar mais tarde.