Micaela 17 de junio de 2009 a las 09.15
   Imprimir artículo
elWebmaster.com

10 tips imperdibles sobre SQL para desarrolladores


database_lockSQL es otro de los lenguajes esenciales en la vida de un desarrollador que se encuentra deseando crear sitios web que manejen información y hagan uso de bases de datos.

Sin embargo, muchos desarrolladores no están familiarizados con varios aspectos del SQL, es por esto que en el siguiente artículo analizaremos 10 consejos esenciales a tener en cuenta sobre este lenguaje.

1. Utiliza el lenguaje correcto

Los desarrolladores web por lo general poseen una gran cantidad de lenguajes a su disposición. Es crucial que seleccionen el ideal para cada trabajo.

Revisemos el código que sigue. En el primer ejemplo, el desarrollador está seleccionando todas las columnas y todas las filas desde la tabla del cliente. En el segundo ejemplo, el desarrollador está seleccionando sólo el primer nombre, apellido y dirección de la tabla del cliente para un cliente particular cuya ID es 1001. El segundo pedido no solo limita las columnas que se devuelven sino que también tiene un mejor desempeño.

SELECT * FROM customer;

SELECT firstName, lastName, shippingAddress FROM customer WHERE customerID = 1001;

Al escribir código es necesario que te asegures que trabaje con eficiencia.

2. Asegura tu código

Las bases de datos almacenan información valiosa. Debido a esto, suelen ser objetivo de ataques. Muchos desarrolladores no están al tanto de que su código posee serios problemas de vulnerabilidad lo que resulta algo muy temido. Actualmente, los desarrolladores pueden tener problemas legales si su propia negligencia en cuanto a los temas de seguridad lleva a que una base de datos sea explotada.

Veamos otro ejemplo utilizando pseudo-código

// Theoretical code
txtUserName.setText(“eshafer’ OR 1=1”);
query = “SELECT username, password FROM users WHERE username = ‘” + txtUserName.getText() + “‘;”;

// Final statement
query = “SELECT username, password FROM users WHERE username = ejshafer OR 1=1;”

Con suerte al ver el código de arriba notaste las vulnerabilidades del mismo. El pedido terminará seleccionando todos los nombres de usuarios y contraseñas grabadas de la tabla, porque 1 es igual a 1. Ahora, este ejemplo particular no tendría mucha importancia para un supuesto hacker. Sin embargo, hay posibilidades casi ilimitadas sobre código adicional malicioso que pueda ser añadido con resultados catastróficos.

¿Cómo puedes escribir código seguro?

La solución es a menudo específico DBMS; que es, una variante entre MySQL, Oracle o SQL Server. En PHP con MySQL, por ejemplo, es usual escapar a los parámetros utilizando la función mysql_real_escape_string antes de enviar el pedido SQL. De forma alternativa, puedes utilizar afirmaciones preparadas para “preparar” tu pedido. Es tu obligación entender el DBMS con el que estás trabajando y los problemas de seguridad inherentes.

La inyección SQL no es el único problema de seguridad con el que los desarrolladores deben tratar, sin embargo, es uno de los más comunes métodos de ataque.

3. Entender las uniones

Las declaraciones SQL de tablas singulares son bastante fáciles de escribir. Sin embargo, los requerimientos de los negocios a menudo hacen que sea necesario escribir pedidos más complejos. Por ejemplo, “encontrar todas las ordenes de un cliente, y mostrar los productos para cada orden”. Ahora, en esta situación particular, sería probable que haya una tabla de cliente, una tabla de orden y una tabla de order_line. Para aquellos que están más familiarizados con SQL, es fácilmente aparente la unión de la tabla, dos tablas juntas serán requeridas para este pedido. Miremos el código de muestra:

SELECT customer.customerID, order.order_id, order_line.order_item
FROM customer
INNER JOIN order
ON customer.customerID = order.customerID
INNER JOIN order_line
ON order.orderID = order_line.orderID;

Para aquellos que no lo saben, el código de arriba es una unión interna. Más específicamente, una equi-join. Definamos los distintos tipos de uniones:

Uniones internas:  Su propósito básico es devolver registros que combinen.

Uniones externas:  No requieren que cada registro tenga un registro que le corresponda.

  • Unión externa izquierda: Una unión externa izquierda de tablas A y B devolverá todos los registros correspondientes de A y B, como así también cualquier registro no-correspondiente de la tabla izquierda.
  • Unión externa derecha: Una unión externa derecha de tablas A y B devolverá todos los registros correspondientes de A y B, como así también cualquier registro no-correspondiente de la tabla derecha.
  • Unión externa completa: Una unión externa completa de tablas A y B devolverá todos los registros correspondientes de A y B, como así también cualquier registro no-correspondiente de ambas.

Uniones propias

Las uniones propias son el último tipo de uniones que debemos considerar: se trata de una union de la tabla a sí misma.

EMPLOYEE TABLE

EmployeeName

SupervisorID

En esta situación, para poder encontrar cuáles empleados son supervisados por un empleado dado, se requerirá una unión propia.

Las uniones son una de las propiedades principales de SQL, así que asegúrate de usar la apropiada para cada situación.

4. Conoce tus tipos de información

En SQL, tradicionalmente cada columna de la tabla posee un tipo de información asociada. Text, Date, VarChar, Integer, etc, son algunos de los tipos disponibles de los cuales los desarrolladores pueden elegir.

Al desarrollar, debes asegurarte de escoger el tipo de información propicio para cada columna. Las fechas deberán ser variables DATE, números deberán ser de tipo numérico, etc. Esto se vuelve especialmente importante al tratar con el tema que sigue:  indexación. Veamos un ejemplo:

SELECT employeeID, employeeName

FROM employee

WHERE employeeID = 112457891;

Parece correcto basado en lo que sabemos hasta ahora ¿No? Sin embargo ¿Qué pasaría si employeeID fuera una cadena?  Tendríamos un gran problema, ya que DBMS puede no encontrar jamás una coincidencia (ya que los tipos de información son de distinto tipo).

Si estás utilizando indexación, probablemente te quedarás perplejo porque tu pedido jamás llegará. Esta es la razón por la que los desarrolladores deben prestar atención especial a los tipos de información en sus aplicaciones.

La utilización debida de los tipos de información es esencial para la buena programación de base de datos, porque ésta guía directamente a la eficiencia del pedido. Y pedidos eficientes son esenciales en la creación de aplicaciones escalables de calidad.

5. Escribe código dócil

Todos los lenguajes de programación poseen estándares que los desarrolladores web deben conocer. SQL fue estandarizado por ANSI y luego ISO, con nuevas revisiones del lenguaje siendo agregadas ocasionalmente. La última revisión es SQL: 2008, aunque la más importante es SQL: 1999. La revisión de 1999 introdujo disparadores, pedidos recursivos, soporte para PL/SQL y T-SQL, y algunas otras propiedades nuevas. También definió que las declaraciones JOIN sean realizadas en la cláusula FROM, en oposición a la cláusula WHERE.

Al escribir el código, es importante tener en mente qué estándares dóciles de código resultan útiles. Existen dos razones principales por la que los estándares son utilizados. La primera es el mantenimiento y la segunda es la estandarización de plataformas cruzadas. El sistema se pasa la mayor parte de su tiempo de vida en fase de mantenimiento. Cuando otro programador acceda a tu código en 2, 5 o 10 años, es necesario que todavía pueda entender lo que tu código está haciendo. Es por eso que los estándares están diseñados para desarrollar la capacidad de mantenimiento.

La otra razón es la funcionalidad de plataformas cruzadas. Con CSS, hay actualmente una batalla de estándares entre Firefox, Internet Explorer, Chrome, y otros navegadores sobre la interpretación del código. La razón para los estándares SQL es prevenir una situación similar entre Oracle, Microsoft y otras variantes SQL como MySQL.

6. Normaliza tu información

La normalización de base de datos es una técnica para organizar el contenido de las mismas. Sin esto las bases de datos pueden ser inapropiadas, lentas e ineficientes. La comunidad de profesionales de base de datos ha desarrollado una serie de guías para la normalización de las mismas. Cada “nivel” de normalización es referido como una forma y existen cinco formas en total.

  • Primer Forma Normal (1NF): Es el nivel más básico de normalización, requiere la eliminación de todas las columnas duplicadas de una tabla, y también la creación de tablas separadas para información relacionada, e identificación de cada tabla con un atributo clave principal.
  • Segunda Forma Normal (2NF): Encuentra todos los requerimientos de la primera forma normal, y crea relaciones entre las tablas utilizando claves extrañas.
  • Tercera Forma Normal (3NF): Encuentra todos los requerimientos de las primeras dos formas, y elimina todas las columnas que no dependan de la clave principal. También elimina todos los atributos derivados, tales como la edad.
  • Cuarta forma Normal (4NF): Adhiere un requerimiento extra, que es la remoción de cualquier dependencia multi-valuada en las relaciones.
  • Quinta Forma Normal (5NF): Es una rara forma de normalización, en la que las dependencias de uniones de caso están implicadas por claves candidatas.

En la realidad de las bases de datos llegar hasta la 3er forma es lo más importante. Si estás luchando con los conceptos, existe una simple relación entre ellos “La clave, la clave completa y nada más que la clave” relaciona a 1NF, 2NF y 3NF.

Los beneficios de la normalización son que a medida que la información progresa a través de las formas se vuelve más clara, mejor organizada y más rápida. A medida que la base de datos crezca, los efectos de la normalización se volverán más aparentes en lo que respecta a velocidad y mantención de la integridad de la información. Sin embargo, existen situaciones en las que la normalización no tiene sentido, como por ejemplo cuando la normalización de la información creará pedidos excesivamente complejos para devolver la misma.

7. Califica completamente los objetos de tu base de datos

Este es un punto comúnmente ignorado. En términos de un desarrollo de base de datos, un nombre de objeto completamente calificado luce así: DATABASE.schema.TABLE. El propósito de un nombre de objeto completamente calificado es eliminar la ambigüedad. Los desarrolladores principiantes raramente tienen acceso a bases de datos múltiples y esquemas, lo que complica el problema en el futuro. Cuando un usuario dado tiene acceso a múltiples bases de datos, múltiples esquemas y las tablas que hay ahí, se vuelve crucial especificar directamente a qué está el usuario intentado acceder.

Clasificar por completo los nombres de tus bases de datos es importante al trabajar con bases de datos grandes que son utilizadas por muchos usuarios y poseen varios esquemas.

8. Entender indexación

El índice de una base de datos es una estructura de información que mejora la velocidad de las operaciones en una base de datos. Los índices pueden ser creados utilizando una o más columnas de la tabla de la base de datos, dando la base tanto de vistazos rápidos al azar como de acceso eficiente a registros ordenados. La indexación es increíblemente importante al trabajar con tablas grandes, sin embargo, ocasionalmente las tablas pequeñas deberían ser indexadas si se espera que crezcan.

Cuando un pedido busca a una base de datos para registros correspondientes, hay dos formas en que la búsqueda puede ser desempeñada:

  • La primera y la más lenta es un escaneo de tabla. En este, el pedido busca cada registro de la tabla en miras de una correspondencia.
  • La segunda y la más rápida es el escaneo indexado. En este, los pedidos buscan el índice para encontrar los registros. En términos de no-base de datos, un escaneo de tabla sería el equivalente a leer cada página de un libro para buscar una palabra, mientras que uno de índice sería el equivalente a dar vuelta al final del libro, encontrar la palabra, ir a la página especifica y luego leer esa página para encontrar la palabra.

Es importante recordar que los índices deben ser reconstruidos ocasionalmente, a medida que información es añadida en la tabla. Por esto, la mayoría de las DBMS poseen una opción para temporalmente deshabilitar un índice para facilitar la modificación masiva de información, y así permitir que sea re-habilitada y reconstruida después.

9. Utilización propicia de los permisos de base de datos

Al trabajar con una base de datos que tiene múltiples usuarios es importante manejar correctamente los permisos. Obviamente, la mayoría de las bases de datos tienen un administrador, pero no siempre tiene sentido correr tus pedidos como administrador. Tampoco desearás proveer a todos los desarrolladores juniors con las credenciales de administrador para que puedan escribir sus propios pedidos. Los varios permisos posibles para tu base de datos dependen de tu DBMS, pero existen temas comunes entre ellos.

En MySQL, por ejemplo, el tipear “SHOW TABLES” revelará una lista de tablas en tu base de datos, en la que más que seguro notarás una tabla “user”. Tipeando ‘DESC user’ revelará que hay varios campos en esta tabla. Junto con un host, nombre de usuario y contraseña, hay también una lista de privilegios que pueden ser programados para cada usuario. Sumado a este, hay una tabla ‘db’ que gobierna privilegios más específicos para una base de datos.

Además, SQL Server provee las declaraciones GRANT, DENY y REVOKE para dar o sacar permisos a un usuario o rol.

10. Conoce las limitaciones de tu DBMS

Las bases de datos son herramientas poderosas pero todas tienen limitaciones. Oracle, SQL Server y MySQL poseen limitaciones propias en ciertas cosas como tamaños máximos de bases de datos, número máximo de tablas y otras cosas. Muchos desarrolladores sin saberlo eligen la solución DBMS para sus proyectos sin planear o considerar los requerimientos de sus bases de datos.

Para conocer las limitaciones puedes referirte al manual de tu DBMS, por ejemplo, las limitaciones de SQL Server están localizadas en el sitio de MSDN: http://msdn.microsoft.com/en-us/library/ms143432.aspx

Conclusión

En este artículo revisamos 10 consejos esenciales para desarrolladores SQL. Sin embargo, existen otras muchas técnicas SQL que pueden ser mencionadas. Continúen desarrollando y recuerden que el código que escriben debe soportar la infraestructura de internet y que sin ustedes, Internet no serían tan exitoso como es.

Fuente: Net Tuts Plus


Enviar a Del.icio.us Enviar a Meneame Enviar a Digg Enviar a Fresqui Enviar a Enchilame

Comentarios (5)

  1. Luis dice:

    Muy buena la info!! pero la llamaria “El Decalogo del Desarrollador de Base de datos”. Todo desarrollador que no tiene en mente la Seguridad y el diseño de la base de datos, no puede ser desarrollador. Esto lo pegaria en mi lugar de trabajo!!!! asi no se olvidan jamas de “el decalogo” del desarrollador.

    Saludos sigan asi con el blog!

  2. Fableton dice:

    Muy buen post pero igual uno que lhaya llevado una clase de BD debe de saber la mayoria, y sobre lo de desarrollador… no se si este mal… pero una partde deben de hacerlo los analistas y otra los desarroladores, en este caso yo creo que desde el analisis todo debe de estar bien implementado… y los desarrolladores no deberian tener problema al escribir todo en codigo…

  3. Moises dice:

    buenisimo.
    quisiera si es posibel que me envien link sobre SQL mas relacionado con Contabilidad.
    Dios los bendiga
    A Jesús por Maria.
    AvaTor

  4. martha dice:

    me encanta obre su informacion me ayuda a conocer mas. gracias

  5. paco dice:

    Quiero decir que el tutorial no está mal del todo, pero estando en una web cuyo nombre es elwebMASTER esperaba encontrar alguno que fuese más desconocido.

    1. La gran diferencia entre indicar el nombre de las columnas y usar *, es que no siempre sabes que columnas tiene la tabla/vista a la que accedes, y no puedes estar 100% seguro de que el DBA modifique la estructura.

    2. Al hablar de seguridad para dar formato a las sentencias y no hablar de las ventajas de seguridad de las vistas frente a las tablas se queda corto.

    3. Lo importante de los JOINS (que no es lo mismo que las UNIONS) es intentar no usarlos. En caso de usarlos lo aconsejable es intentar reducir al máximo las tablas antes de buscar su emparejamiento.

    5. Cuando tienes un montón de datos, hay que tener en cuenta el tiempo que usas el DBMS para que este el mínimo número de usuarios conectados y usar, dentro de lo posible, las consultas más rápidas. En ocasiones usar el “código dócil” no es recomendado. Un ejemplo muy típico: LA PAGINACIÓN.

    6. Esto es completamente falso. Las FN tienen sus ventajas y cuanto más alto puede parecer mejor. Simplemente piensa en una tabla con 2FN que al pasarla a 3FN se te queda en dos. Si tu consulta necesita introducir JOINS puede ser que no te compense por eficiencia pasar a FN superiores. Además si te interesa no tener problemas de actualización-borrado-insertado no te puedes quedar en la 3FN, tienes que llegar como mínimo a la 3FN-BC

    8. Si hablas sobre índices tendrías que mencionar la diferencia que hay entre que este sólo sobre una columna o que esté sobre varias. Además de la importancia de que este entre un tipo TEXT o un TINY.

    9. La gran mayoría de DBMS poseen creación/modificación/borrado de permisos. No es sólo de SQLServer. Además, lo que intentas decir aquí, tiene que ver con los alias.

    10. Es cierto que no existe el DBMS perfecto. Algunos se pueden ajustar mejor en algunos casos que otros. Lo que no debes de poner como limitación es que, por ejemplo Oracle tiene limitación de tamaño o tablas, porque en ese caso (como en SQLServer), la limitación está en el tipo de licencias que posees.

    Así espero que lo puesto ahora te lo tomes como una crítica constructiva. Ahora viene lo malo, es muy “heavy” que este tipo de tutorial esté en una página con ese nombre. No son consejos imprescindibles puesto que en la mayoría de los casos están incompletos.

    Para concluir, tengo que mencionar que debes tener más de una fuente de información para analizar las cosas (y mucho menos hacer una traducción casi literal), porque si no tienes los conocimientos adecuados sobre el tema te pueden meter cualquier “milonga”.

    En definitiva, más que por ti este comentario lo escribo por mi. Motivo: espero que mis futuros alumnos no me vuelvan a decir que algo que digo en clase está mal porque leyeron en alguna pagina web que las cosas son de otra forma y yo tener que perder mi tiempo de clase y tutorías explicando que es lo que está mal en las diversas páginas webs en las que escriben aficionados.

Deja tu opinión

© 2007 - 2008 elWebmaster.com | Powered by Wordpress | Diseño CSS y XHTML válido. | Algunos íconos basados en FamFamFam Mini
Acceder