10 errores comunes sql

Hágale frente - nadie estudia SQL para el gusto de hacerlo. Utilice SQL para crear aplicaciones de bases de datos, pero antes de poder construir uno, necesita una base de datos. Por desgracia, muchos proyectos se tuercen antes se codifica la primera línea de la aplicación. Si usted no recibe el derecho de definición de base de datos, su solicitud está condenado. He aquí diez errores de base de datos de creación comunes que usted debe estar al pendiente de.

No asuma que sus clientes saben lo que necesitan

En general, los clientes que llaman para diseñar un sistema de base de datos cuando tienen problemas para conseguir la información que necesitan porque sus métodos actuales no están funcionando. Los clientes a menudo creen que han identificado el problema y su solución. Calculan que lo único que tienen que hacer es decirle a tú que hacer.

Equivocado. La mayoría de los usuarios no poseen los conocimientos o habilidades necesarias para identificar con precisión el problema, por lo que tienen pocas posibilidades de determinar la mejor solución.

Su trabajo es convencer con mucho tacto a su cliente que usted es un experto en el análisis y diseño de sistemas y que usted debe hacer un análisis adecuado para descubrir la causa real del problema.

No ignore el alcance del proyecto

Su cliente le dice lo que él o ella espera de la nueva aplicación en el inicio del proyecto de desarrollo. Por desgracia, el cliente casi siempre se olvida de decirte algo - por lo general varias cosas. A lo largo del trabajo, estos nuevos requisitos surgen y son añadidas al proyecto.

Si usted está siendo pagado en base a proyectos en lugar de una base horaria, este crecimiento alcance puede cambiar lo que fue una vez un proyecto rentable en un perdedor. Asegúrese de que todo lo que está obligado a entregar se especifica por escrito antes de iniciar el proyecto.

No considere solamente factores técnicos

Los temas de los máximos de costo, la disponibilidad de recursos, requisitos de planificación y la política de la organización pueden tener un efecto importante en el proyecto. Estos problemas pueden convertir un proyecto que es factible en una pesadilla. Asegúrese de que comprende todos los factores no técnicos pertinentes antes de iniciar cualquier proyecto de desarrollo.

No evite la retroalimentación del cliente

Su primer impulso podría ser la de escuchar a los directivos que te contratan. Después de todo, los usuarios seguro que como diablos no pagan su cuota. Por otro lado, puede haber una buena razón para ignorar los gestores, también. Por lo general, no tienen ni idea de lo que los usuarios realmente necesitan. ¡Espera un minuto!

No ignore todo el mundo o asumir que usted sabe más que un gerente o usuario sobre cómo debe funcionar una base de datos. Secretarios de entrada de datos no suelen tener mucha influencia de la organización, y muchos gerentes tienen sólo un conocimiento débil de algunos aspectos de la obra que los empleados de entrada de datos hacen. Pero aislar a sí mismo de los dos grupos es casi seguro que resultará en un sistema que resuelve un problema que nadie tiene.

No siempre se puede utilizar el entorno de desarrollo favorito

Usted probablemente ha pasado meses o incluso años convertirse en experto en el uso de un DBMS o aplicación entorno de desarrollo en particular. Pero su entorno favorito - no importa lo que es - tiene fortalezas y debilidades.

Así que en lugar de kludge juntos algo que en realidad no es la mejor solución, de tripas corazón. Usted tiene dos opciones: o bien subir la curva de aprendizaje de una herramienta más apropiada y luego usarlo, o sinceramente decirle a sus clientes que su trabajo mejor se haría con una herramienta que usted no es un experto en el uso.

Luego sugiere que el cliente contratar a alguien que puede ser productivo con esa herramienta de inmediato. Conducta profesional de este tipo granjea el respeto de sus clientes. (Desafortunadamente, si usted trabaja para una empresa en lugar de por sí mismo, que la conducta puede también conseguirle despedido o despedida.)

No utilice exclusivamente la arquitectura de su sistema favorito

Nadie puede ser un experto en todo. Sistemas de gestión de base de datos que funcionan en un entorno telemático son diferentes a los sistemas que funcionan en cliente / servidor, el intercambio de recursos, basada en la web, o entornos de bases de datos distribuidas. Elija la mejor arquitectura de todos modos, incluso si esto significa que pasa en el trabajo. No conseguir el trabajo es mejor que conseguir y producir un sistema que no sirve a las necesidades del cliente.

No diseñe las tablas de bases de datos en aislamiento

Si usted se identifica incorrectamente objetos de datos y sus relaciones entre sí, sus tablas de la base es probable que introducir errores en los datos y destruir la validez de los resultados. Para diseñar una base de datos de sonido, debe tener en cuenta la organización general de los objetos de datos y cuidadosamente determinan la forma en que se relacionan entre sí. Usted debe determinar lo que es apropiado, teniendo en cuenta la actualidad de su cliente y las necesidades previstas.

No se olviden de las revisiones de diseño

Incluso el mejor diseñador y desarrollador puede perder puntos importantes que son evidentes para alguien que busca la situación desde una perspectiva diferente. La presentación de su trabajo antes de una revisión formal del diseño puede hacerte más disciplinado en su trabajo. Tener una opinión profesional competente su diseño antes de comenzar el desarrollo. Usted debe tener un diseñador de la base de datos comprobarlo otra vez, pero es posible que desee mostrar al cliente, también.

No se salte las pruebas beta

Incluso si lo pruebas en todos los sentidos que se pueda imaginar, la aplicación es segura para contener los modos de fallo que no descubrirás. Las pruebas beta significa renunciar a la aplicación a las personas que no saben que fue diseñado.

Son propensos a tener problemas que nunca encontramos, porque usted sabe demasiado acerca de la aplicación. A continuación, puede corregir los errores o deficiencias de desempeño que otros encuentran antes que el producto va oficialmente en uso.

No te olvides de documentar su proceso

Si cree que su aplicación es tan perfecto que nunca necesita ser mirado, ni siquiera una vez más, se equivoca. La única cosa que usted puede estar absolutamente seguro de en este mundo es el cambio. Cuenta con eso. Seis meses a partir de ahora, usted no recordar por qué usted diseñó las cosas de la manera que lo hizo, a menos que usted documenta cuidadosamente lo que hizo y por qué lo hizo de esa manera.

El exceso de documentar su trabajo. Ponga con más detalle de lo que piensa es razonable. Se dará sus frutos más adelante.