El Blog de George

Visiten mi nuevo Blog

2009-12-21T11:55:00.000-08:00

En el nuevo blog encontrar toda la informacion q he publicado hasta ahora, como muchas cosas nuevas. Proximamente tb publicare codigo en Vb. Net
click Aqui

House 6 Temporada - Capitulo 3

2009-11-28T09:04:00.000-08:00

House 6 Temporada - Capitulo 1 y 2

2009-11-28T08:58:00.001-08:00

Triggers y Procedimientos Almacenados en MySQL

2009-11-27T08:27:00.000-08:00

Unas opciones no muy usadas cuando se trabaja con MySQL son los triggers y los procedimientos almacenados (stored procedures), supongo que a que es algo nuevo en MySQL y la gente no está acostumbrada a estas dos funcionalidades.

Vamos a mostrar un ejemplo de uso de triggers y procedimientos almacenados paso a paso. Quizás el ejemplo no sea el más correcto, o simplemente sea poco útil, pero lo importante es el uso en sí, no el ejemplo.

Nuestro sistema tendrá dos tablas, una con ventas y la otra con comisiones. En la primera se almacenarán cada venta que se realiza en un comercio, y en la segunda las comisiones que le corresponden a cada vendedor en el momento.

CREATE TABLE `ventas` (
  `vendedor` int(11),
  `producto` int(11),
  `importe` float
)
 
CREATE TABLE `comisiones` (
  `vendedor` int(11),
  `comision` float
)

Las comisiones se calcula de una forma especial, le corresponde un porcentaje de las ventas según el tipo de producto, y es importante para los vendedores el que se sepa en cada momento qué comisiones lleva ganadas (esto es una justificación para no usar un cron o algo parecido).

Para calcular qué comisión le corresponde a un vendedor, calcularemos los porcentajes para cada tipo de producto vendido y luego lo añadiremos/actualizaremos en la tabla de comisiones. Todo se realizará en un procedimiento almacenado.

DELIMITER $$
DROP PROCEDURE IF EXISTS `test`.`sp_comisiones`$$
CREATE PROCEDURE `test`.`sp_comisiones` (IN mivendedor INT)
BEGIN
 DECLARE micomision INT DEFAULT 0;
 DECLARE suma INT;
 DECLARE existe BOOL;
 
 select IFNULL(sum(importe),0) into suma from ventas where producto = 1 and vendedor = mivendedor;
 SET micomision = micomision + (suma * 0.15);
 
 select IFNULL(sum(importe),0) into suma from ventas where producto = 2 and vendedor = mivendedor;
 SET micomision = micomision + (suma * 0.1);
 
 select IFNULL(sum(importe),0) into suma from ventas where producto = 3 and vendedor = mivendedor;
 SET micomision = micomision + (suma * 0.2);
 
 select count(1)>0 into existe from comisiones where vendedor = mivendedor;
 if existe then
  UPDATE comisiones set comision = comision+micomision where vendedor = mivendedor;
 else
  insert into comisiones (vendedor, comision) values (mivendedor, micomision);
 end if;
END$$
 
DELIMITER ;

Ahora, para actualizar los datos de las comisiones usaremos un trigguer, así cuando se haga una venta (insert en la tabla ventas), se llamará al procedimiento almacenado (sp_comisiones), que recalculará la comisión para ese vendedor.

DELIMITER $$
DROP TRIGGER `test`.`tr_ventas_insert`$$
CREATE TRIGGER `test`.`tr_ventas_insert` AFTER INSERT on `test`.`ventas`
FOR EACH ROW BEGIN
 call sp_comisiones(new.vendedor);
END$$
DELIMITER ;

Manual WML - Parte VI Final

2009-11-27T08:19:00.000-08:00

Las URL
relativas o absolutas

Puede ocurrir que el dispositivo WAP o el gateway no interprete correctamente una URL relativa. Para evitar esto ser recomienda usar la URL absoluta:

NO	SÍ
<a href="../foo/bar.wml"> <a href="#myID">	<a ref="http://my.server.com/foo/bar.wml"> <a href="http://my.server.com/foo/bar.wml#myID">

Nombre de variables
y ficheros

No olvides que los datos se envian y reciben a través del aire. La velocidad suele se de 9600. Intenta que se envien el menor volumen de datos posible.
Idea 1: Usa nombres de ficheros lo más cortos posibles. Ej: http:"//my.server.com/i.wml" mejor que http://my.server.com/index.wml
Idea 2: Usa nombres de variables lo más cortos posibles. Si usas menos de 25 variables lo mejor es que uses las letras del alfabeto.

Imágenes

Cuidado. No todos los dispositivos WAP aceptan imágenes. Utilízalas lo menos posible. Alguna SDK si las aceptan, pero... Y si las utilizas no te olvides nunca de poner el atributo alt <img src="imagen.gif" alt="Icono" />

Nombre de variables
y ficheros

¿Has intentado alguna vez escribir un password en un teléfono móvil? Es muy fácil en un PC o en un PDA, pero en un teléfono... Procura no usar el atributo type="password" en los input

¿Listas o Links
normales?

Hay dos formas de crear una lista de 2 links, con un select o con a. Recomendamos la segunda por lo que se explica abajo

NO	SÍ
<select ivalue="0"> <option onpick="#Card2">Link 1</option> <option onpick="#Card3">Link 2</option> </select>	<p><a href="#Card2">Link 1</a></p> <p><a href="#Card3">Link 2</a></p>
Así se va a ver	Así se va a ver
aaaa bbb El problema es que como aparece seleccionado el primer link, no podemos accionarlo, y si bajamos al segundo, se inicializa el evento onpick y nos vamos a al Card3	Link 1 Link 2

Newcontext="true"

&Iquest;Has visto en el código de alguna página <card id="card1" title="Currency" newcontext="true">? ¿ Lo has probado?
Si pones ese atributo, las variables se borran, incluso la history, por lo que no se puede usar el back. Para inicializar variables es mejor
<card title="Titulo">
<<onevent "onenterforward">
<refresh>
<setvar name="Var1" value="
"/>
<setvar name="some_var2" value="
"/>
</refresh>
</onevent>
...
</card>

Pasar datos a ASP o
CGI

Por ejemplo con un
input:
<input format="NN" name="Var1" title="Var1:"/>
<do
type="accept" label="Mandar:">
<go
href="http://*****/test.asp?datos=$(Var1)"/>

Detectar en el
servidor si se accede con un dispositivo WAP

Sorry, pero no lo he traducido...
XP
Sacado de http://www.egroups.com/group/wmlprogramming

I tried to redirect my browser clients using ASP and following your sample
code. For some reason the content type is text/html. I submit the code see if
any of you can see whats wrong. The redirect woks fine when I use the web
browser.

---------code-----------------------------------------------------

<%Response.ContentType = "text/vnd.wap.wml"%>
<% Dim uastring,
wmlURL, htmlURL
uastring = request.ServerVariables("HTTP_USER_AGENT")

wmlURL = "/martin/index.wml"
htmlURL = "some URL"
If
(InStr(uastring,"UP") Or InStr(uastring, "Nokia") Or InStr(uastring,
"Wap"))
Then
Response.Redirect wmlURL
else

Response.Redirect htmlURL
End If %>

-------End of code---------------------------------------
Marco

The only problem with this approach is when you encounter a phone that does
not support WMLScript, or your site gets hit by an HTML client. You're much
better off checking on the server end first. This is a trivial exercise in just
about any language, Perl, ASP, Java, etc...

In Perl 5
#!/usr/local/bin/perl5

$ua = $ENV{"HTTP_USER_AGENT"};
if ($ua =~ "UP"){ print "Status: 302 Moved
Temporarily\r Location: <one location>"; } elsif($ua =~ "Nokia"){ ...

You get the picture.

In asp, this construct would look like:

Dim uastring
uastring = request.ServerVariables("HTTP_USER_AGENT")
If
(InStr(uastring,"UP"))Then Response.Redirect(<onelocation>)

and in a Java Servlet it would look like this:

String ua = req.getHeader(HTTP_USER_AGENT);
if (ua.indexOf("UP")!= null){

res.setStatus(res.SC_MOVED_TEMPORARILY);
res.setHeader("Location",
<one location>);

Manual WML - Parte V

2009-11-27T07:51:00.000-08:00

17-La etiqueta
postfield

Los atributos de esta etiqueta son:

Etiqueta	Explicación	Valores que puede tomar
name	Nombre de la variable que va a enviar el usuario(Obligatorio)	Texto
value	Valor que toma la variable a enviar	Texto
Notas: Atención: Normalmente los datos deben ser enviados en formato escape al servidor, por lo que si los recibimos de un input debemops transformarlos(<postfield name="f" value="$(datos:e)"/> este tema se amplia en variables) Se utiliza dentro de una etiqueta go. Acaba siempre con una barra /. No todos los dispositivos WAP (Ej. Nokia 7110) aceptan el envio de datos
Ejemplo <go method="post" href="http://www.empresa.com/cgi/banco"> <postfield name="Dinero" value="10000"/> <postfield name="Num_Cta" value="12345"/> <postfield name="Operacion" value="Deposito"/> </go>		Explicación: Enviamos los campos Dinero=10000, Num_Cta=12345 y Operacion=Deposito al servidor

18- La etiqueta setvar

Los atributos de esta etiqueta son:

Etiqueta	Explicación	Valores que puede tomar
name	Nombre de la variable que va a inicializar(Obligatorio)	Texto
value	Valor que toma la variable	Texto
Notas: Se suele utilizar dentro de otras etiquetas. Acaba siempre con una barra /
Ejemplo <go href="#card2"> <setvar name="Anterior" value="Card1" /> </go>

19- Las variables. Nombres y Usos

Las variables, siguen el formato normal de la gran mayoría de lenguajes. Deben empezar por una letra o guión bajo y pueden seguir por otras letras, guiones o números. No uses símbolos ni eñes y ni mucho menos el signo dólar &. Las variables son Case Sensitive, lo que implica que diferencian mayúsculas de minúsculas, Variable no es lo mismo que variable, ni que VaRiAbLe.

Sustitución de variables: A veces queremos que una valor o atributo sea sustituido por los datos que hay almacenados en una variable, y esto se consigue anteponiendo el signo dolar al nombre de la variable entre paréntesis.
Ej.
<input type="text" name="Nombre"/><postfield name="dato1" value="Nombre"/> Esto lo que hace es pasar al servidor el campo dato1 con el valor Nombre, no el nombre que introdujo el usuaior
<input type="text" name="Nombre"/><postfield name="dato1" value="$(Nombre)"/> Esto lo que hace es pasar al servidor el campo dato1 con el nombre que el usuario ha escrito en el input. (Cuidado aún tiene un pequeqo fallo que explicamos ahora).

Caracteres de escape: A veces los servidores necesitan obtener la información en formato de caracteres de escape(el típico
http:\\empresa.com\bancos?%24insertar%24%26true), o una información
obtenida en este formato pasarla a normal. Para ello usamos las transformaciones que implementa WML.
$(nombre_variable:e) --> Pasar a formato escape --> Si el valor de la variable es abc=? nos da
abc%3D%3F
$(nombre_variable:unesc) --> Pasar a formato unescape -->Si el valor de la variable es abc%3D%3F nos da abc=?

Manual WML - Parte IV

2009-11-26T14:12:00.000-08:00

13- La etiqueta
input

Los atributos de esta etiqueta son:

Etiqueta	Explicación	Valores que puede tomar
name	Nombre de la variable que va a tomar los datos que introduzca el usuario(Obligatorio)	Texto
value	Valor que aparece en el campo input por defecto. Debe cumplir las reglas de formato de este campo o si no será ignorado; También será ignorado si la variable ya tiene un valor previo	Texto
type	Forma en la que se introducen los datos	text Texto normal password Aparecen asteriscos en vez del texto tecleado. NO se recomienda, ya que para escribir con un telef. móvil es muy complicado
format	Formato en que se acepta la introducción de datos	El formato por defecto es M, o sea cualquier caracter en mayúsculas. A= Cualquier caracter no numérico en mayúsculas a= Cualquier caracter no numérico en minúsculas N= Sólo números X= Cualquier caracter en mayúsculas x= Cualquier caracter en minúsculas \dato=* Dato es un valor que queremos que aparezca tal cual
emptyok	En true si queremos que no sea obligatorio introducir este dato, ya que si tenemos un formato en un campo y no queremos cubrirlo, si lo dejamos en blanco puede no cumplir el formato, lo que nos da un error	True o false(Por defecto si el campo tiene formato)
size	Especifica el ancho en caracteres del input	Número
maxlenght	Especifica el número máximo de caracteres a introducir	Número
title	Título usado en la presentación del objeto	Texto
tabindex	Especifica el orden en que se accede a los distintos objetos dentro de una card. Por defecto de arriba a abajo	Número
Notas: Siempre se acaba la etiqueta con una barra /
Ejemplo <input type="text" name="ape1" format="A" maxlength="25" emptyok=true /> Acepta 25 letras en mayúsculas y las almacena en la variable ape1. No es un campo obligatorio(emptyok=true) <input type="text" name="fecha" format="NN\-NN\-19NN" maxlength="10"/> Acepta solamente números y ya pone el los quiones y el 19, almacenando esto en la variable fecha. Es un campo obligatorio

14- La etiqueta select

Los atributos de esta etiqueta son:

Etiqueta	Explicación	Valores que puede tomar
name	Nombre de la variable que va a tomar los datos que introduzca el usuario(Obligatorio)	Texto
value	Valor que tiene la variable por defecto.	Texto
multiple	Posibilidad de seleccionar más de una opción. Si es así el valor de la variable será ambos valores separados po ;	True ó False(por defecto)
ivalue	Deternima el index de la opción que queremos que esté seleccionada por defecto. El primer item es 0, el segundo 1....	Número
title	Título usado en la presentación del objeto	Texto
Notas: Siempre utilizaremos la opción ivalue=0, o al menu que queremos que sea seleccionado por defecto. Siempre se acaba con la etiqueta </select>. Dentro de esta etiqueta deben ir <option> o <optgroup>
Ejemplo: Se ven en las siguientes etiquetas

15- La etiqueta option

Los atributos de esta etiqueta son:

Etiqueta	Explicación	Valores que puede tomar
value	Valor que toma la variable al seleccionar este item	Texto
title	Título usado en la presentación del objeto	Texto
onpick=	Evento que ocurre al seleccionar o deseleccionar un item	Href. URL o dirección de otra card
Notas: Siempre se acaba con la etiqueta </option>. Debe estar dentro de la etiqueta <select>
Ejemplo: <select name="mascota" value="N" ivalue=1> <option value="N">Ninguno</option> <option value="P">Perro<</option> <option value="G">Gato<</option> </select>	Explicación: Tenemos 3 opciones, y por defecto Ninguno seleccionada(ivalue=1). Sólo podemos elegir 1 de ellas. Si elegimos Perro, la variable mascota es P, gato es G y si no elegimos nada N(value="N").

16- La etiqueta optgroup

Los atributos de esta etiqueta son:

Etiqueta	Explicación	Valores que puede tomar
title	Título usado en la presentación del objeto	Texto
Notas: Siempre se acaba con la etiqueta </optgroup>. Esta etiqueta es usada para aglurinar a varias option
Ejemplo: <select name="Pais"> <optgroup title="América"> <option value="USA">USA</option> <option value="Mex">México</option> </optgroup> <optgroup title="Europa"> <option value="Esp">Espaqa</option> <option value="Fra">Francia</option> </optgroup> </select>	Explicación: Tenemos 2 opciones dentro de cada subgrupo. Sólo podemos elegir 1 de ellas. Primero seleccionamos el continente, y dependiendo del seleccionado, nos salen las siguientes opciones, y allí elegimos el valor que asignaremos a la variable Pais

Manual WML - Parte III

2009-11-26T13:54:00.000-08:00

9- La etiqueta
a

Los atributos de esta etiqueta son:

Etiqueta	Explicación	Valores que puede tomar
title	El texto que sale al entrar en las opciones	Texto
href	Dirección a la que accederemos	Href. URL u otra card
Notas: Se cierra con </a>
Ejemplo <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <card id="links" title="Links"> <p> Este es un texto normal, pero aquí hay un <a title="LINK" href="#card2">link! </a> </p> </card> <card id="card2" title="Segunda Card"> <p align="center"> <br/> Estamos en la <br/> Card2 </p> </card> </wml> Explicación: Aparece en la pantalla: Este es un texto normal, pero aquí hay un link! y en la barra de navegación del browser aparece options. Al acceder a options nos aparece la lista de links activos(en este caso solamente uno).

10- La etiqueta
timer

Los atributos de esta etiqueta son:

Etiqueta	Explicación	Valores que puede tomar
id	Identificador del objeto. Usado para referirse a ella	Texto
value	Tiempo que debe pasar para que se inicialize el evento. Se expresa en décimas de segundo	Número
Notas: Si se utiliza una etiqueta timer, siempre hay que definir en la card el valor ontimer, bién sea a otra card ontimer="#card2" u a otra URL ontimer="http://otraempresa.com/pub/inicio.wml"
Ejemplo <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <card id="card1" ontimer="#card2" title="Demostrando un timer"> <timer value="35"/> <p align="center"> <br/> <big> Bienvenidos a ... </big> </p> </card> <card id="card2" ontimer="#card3" title="Demostrando un timer"> <timer value="50"/> <p align="center"> <br/> <b> WAP facil<br/></b> <u> Wireless Application Protocol </u> ... </p> </card> <card id="card3" title="Demostrando un timer"> <p align="center"> <br/> <big><i> El mejor curso! </i></big> </p> </card> </wml> Explicación: Lo primero que vemos es una pantalla con un texto que dice Bienvenidos a ... y al cumplirse el timer <timer value="35"/>, pasa a la siguiente y al cumplirse el timer de esta se pasa a la última.

11- La etiqueta img

Los atributos de esta etiqueta son:

Etiqueta	Explicación	Valores que puede tomar
src	Lugar donde se encuentra la imagen	Href. Por ahora solamente se aceptan ficheros .wbmp, pero en un futuro se aceptarán GIF y JPG(El Nokia WAP Toolkit 1.2 acepta GIF y JPG) . Descárgate el conversor de ficheros PULSANDO AQUÍ
alt	Texto alternativo. Se recomienda usarlo siempre	Texto
vspace y hspace	Espacio en blanco entre la imagen y el resto de contenidos. Si es expresado en porcentaje, representa el espacio total de visión del browser, no las medidas de la imagen	Número o porcentaje
align	Alineación del texto con respecto a la imagen	top, middle o bottom
height y width	Alto y ancho de la imagen(por este orden)	Número
id	Identificador del objeto. Usado para referirse a ella	Texto
Notas: Siempre se debe utilizar la propiedad alt, ya que al estar WML aún en desarrollo, nunca sabemos si el navegador que se está usando acepta imágenes. Esta etiqueta siempre acaba con una barra /
Ejemplo <img src="./images/ojo.wbmp" alt="ojo" align="middle" />

12- La etiqueta table

Los atributos de esta etiqueta son:

Etiqueta

Explicación

Valores que puede tomar

title

Título de este elemento.

Texto

colums

Número de columnas que van a ser representadas. Se recomienda usarlo siempre. El valor 0 es un error en WML

Número

align

Alineación del texto dentro de su celda

L= Izquierda
C= Centro
R= Derecha

Identificador del objeto. Usado para referirse a el

Texto

<tr>

Definición de salto de línea. Se cierra con </tr>

Ninguno

<td>

Definición de salto de columna. Se cierra con </td>

Ninguno

Ejemplo

<table
columns=2>
<tr>
  <td>Pais</td><td>l/m2</td>
</tr>
<tr>
  <td>Suiza</td><td>1,3</td>
</tr>
<tr>
  <td>Francia</td><td>2,5</td>
</tr>
</table>

Ventana del browser

Pais	l/m2
Suiza	1,3
Francia	2,5

Manual WML - Parte II

2009-11-26T12:59:00.000-08:00

5- La etiqueta access

Los atributos de esta etiqueta son:

Etiqueta	Explicación	Valores que puede tomar
id	Nombre de la etiqueta. Usado para referirse a ella	Texto
domain	Dominio de acceso	Href
path	Dirección de acceso	Href
Notas: Atención Esta etiqueta debe ir dentro de la etiqueta <head> AQUI </head>. Si no se aplica la etiqueta access el acceso es libre.
Ej. <access domain="miempresa.com" path="/pub"> Se accede a: miempresa.com/pub/stock.asp , miempresa.com/pub/demos/ventas.cgi No se accede a: miempresa.com/cgi-bin/ , otraempresa.com/index.wml

6- La etiqueta
do

Los atributos de esta etiqueta son:

Etiqueta	Explicación	Valores que puede tomar
name	Nombre del objeto. Usado para referirse a ella	Texto
label	Texto que aparece al pulsar el botón options en el navegador para iniciar el evento	Texto
type	Define el tipo de evento que se va a realizar	accept Aceptar prev Ir atrás reset Resetea el estado actual options Operaciones opcionales delete Borra un objeto o selección
Notas: Las etiquetas que pueden ir dentro de un do son <go href="...."/>, <prev/>, <noop/>, <refresh/>. Si una etiqueta do tiene el mismo name que otra definida en la template se usa la de esta card.
Ejemplo Si quieres ver este ejemplo en acción con fotografías del teléfono móvil PULSA AQUI y se abrirá otra ventana

7- La etiqueta go

Los atributos de esta etiqueta son:

Etiqueta	Explicación	Valores que puede tomar
href	Dirección a la que se quiere ir	Href. Url o nombre de otra card
method	Utilizado para enviar datos al servidor. Se amplia con el tema postfield	post o get
Notas: esta etiqueta siempre acaba con una barra <go href="..."/>
Ejemplo Si quieres ver este ejemplo en acción con fotografías del teléfono móvil PULSA AQUI y se abrirá otra ventana

8- Las etiquetas prev, noop y refresh

Estas etiquetas no tienen atributos

Etiqueta	Explicación	Ejemplo
<prev/>	Ir a la página anterior	<do type="accept" label="Oprima select"><go href="#card2"/></do>
<noop/>	Ninguna operación	<do type="accept" label="Oprima select"><noop/></do>
<refresh/>	Resetea los valores	<do type="accept" label="Oprima select"><refresh/></do>
Notas: estas etiquetas siempre acaban con una barra /

Heroes 5 Temporada: Redemption Capitulo 11 Thanksgiving

2009-11-24T05:51:00.000-08:00

Manual WML - Parte I

2009-11-23T08:03:00.000-08:00

Lo primero es lo primero. Si no tienes ni idea de HTML, lo veo muy dificil. Lee el manual de HTML que hay en la URL http://www.wmaestro.com/. Si te quieres arriesgar, es cosa tuya, pero te advierto que se parte de la base de que se controla el tema de la edición de páginas HTML.

- Las páginas hechas en WML tiene extensión .wml, los scripts .wmls y los dibujos .wbmp

- Este es el encabezado que define la versión de WML que usamos:

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml">

No lo vamos a explicar ya que es un tema avanzado. Simplemente es lo que pondremos al principio de nuestra página.

- Como en el HTML el resto del código va entre las etiquetas <wml> y </wml>. Ej.:

<?xml version="1.0"?>

<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml">

<wml>

Aquí va el código

</wml>

- Una página se denomina deck(baraja) y se subdivide en cards(cartas), de tal forma que podemos movernos por varias cards dentro de la misma deck. Ej.:

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
<card id="First_Card">
<do type="accept" label="Next">
<go href="#Second_Card"/>
</do>
<p>
Select <b>Next</b> to display the next card.
</p>
</card>
<card id="Second_Card">
<p>
This card contains the following:...
</p>
</card>
</wml>

Esto define un deck que contiene 2 cards, de tal forma que cuando pulsemos Next nos iremos a la segunda card, en la cual podremos elegir la opción Back para volver a la anterior. El objeto y propiedades de card se definirán más adelante.

2- El formateo de los textos

Lo primero que debemos aprender es el formateo de los textos, para conseguir una presentación aceptable de nuestros datos, cosa difícil debido al pequeño espacio que se nos proporciona en el navegador WML. TODOS los textos deben ir dentro de una etiqueta <p> Textos....</p>

Etiqueta	Uso
<em> <strong> <i> <b> <u> <big> &lt,small>	Texto con énfasis Texto con mucho énfasis Texto con cursiva Texto con negrilla Texto con subrayado Texto con letra grande Texto con letra pequeña

Ej.:El código <b>Hola</b>a todos --> Hola a todos // <b><i>Hola</b></i>a todos --> Hola a todos

La alineación también es importante, y esta se consigue utilizando la etiqueta <p align="...."> Texto </p>. En la siguiente tabla vemos los usos de la misma.

Alineado a la izquierda (Por defecto)	Alineado al centro	Alineado a la derecha
<p align="left"> El resultado final <br/>es el siguiente </p>	<p align="center"> El resultado final <br/>es el siguiente </p>	<p align="right"> El resultado final <br/>es el siguiente </p>
El resultado final es el siguiente	El resultado final es el siguiente	El resultado final es el siguiente

La etiqueta <br/> se utiliza para hacer un salto de línea RECUERDA que igual que en HTML, hay ciertos caracteres que no se pueden escribir literalmente

Caracteres especiales
á é í ó ú ñ & cedilla " abrir comillas cerrar comillas apóstrofe < > nbsp $	á é í ó ú ñ &#38 ç " « » ' < > $$

3- La etiqueta card Los atributos de esta etiqueta son:

Etiqueta	Explicación	Valores que puede tomar
id	Nombre de la card. Usado para referirse a ella	Texto
title	Es el título que sale en la parte superior del navegador al entrar en la card	Texto
newcontext	Borra el historial de navegación. Resetea todas las variables. Sólo actúa al realizar el evento go.	True ó false(valor por defecto)
ordered	No se explica por el momento	True(valor por defecto) ó false
onenterforward	Dirección a la que se va al ocurrir este evento(ir adelante) usando la etiqueta go.Se amplia más adelante	Href. URL o dirección de otro card.
onenterforward	Dirección a la que se va al ocurrir este evento(ir atrás) usando la etiqueta go.Se amplia más adelante	href. URL o dirección de otro card.
ontimer	Dirección a la que se va al ocurrir este evento(reloj) usando la etiqueta timer.Se amplia más adelante	Href. URL o dirección de otro card.
Ej. <card id="card_1" title="Primera Card" onenterforward="http://www.wapserver.com/3.wml" onenterbackward="http://www.wapserver.com/1.wml" ontimer="#card_2"> Resto del código </card>

4- La etiqueta template
Los atributos de esta etiqueta son:

Etiqueta	Explicación	Valores que puede tomar
id	Nombre de la plantilla. Usado para referirse a ella	Texto
onenterforward	Dirección a la que se va al ocurrir este evento(ir adelante) usando la etiqueta go.Se amplia más adelante	Href. URL o dirección de otro card.
onenterforward	Dirección a la que se va al ocurrir este evento(ir atrás) usando la etiqueta go.Se amplia más adelante	href. URL o dirección de otro card.
ontimer	Dirección a la que se va al ocurrir este evento(reloj) usando la etiqueta timer.Se amplia más adelante	Href. URL o dirección de otro card.
Notas: Como una plantilla que es, sus valores se aplican a todas las cards que definamos en esa página WML. Atención Si dentro de una card definimos un evento onenterforward, onenterbackward u ontimer con el mismo id que en la plantilla el que se utiliza es el definido en la card.
Ej. <template id="Template_1"> <do type="options" name="hazlo" label="Default"> Código eliminado... </do> </template> <card id="Card_1"> <do type="options" name="hazlo"> Esta definición sobreescribe la de la plantilla para esta card al tener el mismo nombre Código eliminado... </do> </card>

Web Services en PHP - Parte IX Final

2009-11-21T09:00:00.000-08:00

Código de mostrarPronostico.php

<?php
/**
* Codigo para consumir un servicio web (Web Service) por medio de NuSoap
* La distribucion del codigo es totalmente gratuita y no tiene ningun tipo de restriccion.
* Se agradece que mantengan la fuente del mismo.
*/
// Le indicamos a PHP que no muestre los Notices (por si el servicio no retorna datos)
// (esto se puede evitar preguntando si hay datos antes de mostrarlos)
error_reporting(1);
// Inclusion de la libreria nusoap (la que contendra toda la conexión con el servidor
//require_once('lib/nusoap.php');
$oSoapClient = new soapclient('http://live.capescience.com/wsdl/GlobalWeather.wsdl', true);
if ($sError = $oSoapClient->getError()) {
echo "No se pudo realizar la operación [" . $sError . "]";
die();
}
// Viene de un POST => Selecciono una ciudad
if ($_SERVER["REQUEST_METHOD"] == "POST") {
$aParametros = array("code" => $_POST["codLocalidad"]);
$aRespuesta = $oSoapClient->call("getWeatherReport", $aParametros);
}
// Existe alguna falla en el servicio?
if ($oSoapClient->fault) { // Si
echo 'No se pudo completar la operación';
die();
} else { // No
$sError = $oSoapClient->getError();
// Hay algun error ?
if ($sError) { // Si
echo 'Error:' . $sError;
}
}
?>
<html>
<body>
<table width="367" border="0" cellspacing="0" cellpadding="0">
<tr>
<td colspan="2"><div align="center">Datos del tiempo</div></td>
</tr>
<tr>
<td width="147"> </td>
<td width="220"> </td>
</tr>
<tr>
<td>Nombre:</td>
<td><?=$aRespuesta["station"]["name"];?></td>
</tr>
<tr>
<td>Elevación:</td>
<td><?=$aRespuesta["station"]["elevation"]; ?></td>
</tr>
<tr>
<td>Fecha y Hora:</td>
<td><?=$aRespuesta["timestamp"];?></td>
</tr>
<tr>
<td>País:</td>
<td><?=$aRespuesta["station"]["country"];?></td>
</tr>
<tr>
<td>Latitud:</td>
<td><?=$aRespuesta["station"]["latitude"];?></td>
</tr>
<tr>
<td>Longitud:</td>
<td><?=$aRespuesta["station"]["longitude"];?></td>
</tr>
<tr>
<td>Presión:</td>
<td><?=$aRespuesta["pressure"]["string"];?></td>
</tr>
<tr>
<td>Temperatura:</td>
<td><?=$aRespuesta["temperature"]["string"];?></td>
</tr>
<tr>
<td>Visibilidad:</td>
<td><?=$aRespuesta["visibility"]["distance"];?> mts.</td>
</tr>
</table>
</body>
</html>

Web Services en PHP - Parte VIII

2009-11-20T15:54:00.000-08:00

¿Cómo lo podemos usar?:

Existen muchas formas en que podríamos usar este Web Service, podemos dejar que el visitante seleccione su país y localidad, y que nuestro sitio le retorne cual es el pronostico actual (solo deberíamos incorporar un paso anterior al que se ofrece en el código, el de selección del país).

Otro uso que podemos darle es el de mostrar cual es el clima actual para una localidad determinada (lo mismo que hacen muchos diarios en sus cabeceras). Si decidimos implementar la segunda opción debemos tener especial cuidado en como lo hacemos, ya que si por cada petición que haga el usuario debemos conectarnos con el servidor que ofrece el web service, esto provocaría una gran demora para el usuario, y una sobrecarga innecesaria del servidor. Para solucionar esto podemos guardar en un archivo de texto o en una base de datos, el clima actual, para leerlo desde allí. Este archivo, o base de datos, la actualizaríamos cada un tiempo prudencial (como puede ser una hora o más).

Otros Web Services:

Actualmente existen gran cantidad de Web Services, gratuitos y no. En el sitio de XMethods pueden encontrar gran cantidad de ellos. Sin ir más lejos Google ofrece un web service para realizar búsquedas (solo hay que registrarse en http://www.google.com/apis/) y nos permitirá realizar 1000 consultas por día (creo que puede ser más que interesante para muchos).

Conclusión:

Los Web Services son un tema apasionante, ya que brindan gran funcionalidad y posibilidad de realizar cambios y mejorar nuestras aplicaciones. Un mismo web service puede ser consumido tanto por aplicaciones que se ejecutan en un servidor y entregan código html al cliente, como por aplicaciones que corren directamente en la máquina del cliente. Como vemos las posibilidades son infinitas, es sólo cuestión de comenzar a experimentar.

Apéndice:

Código de seleccionarLocalidad.php

/**

* Codigo para consumir un servicio web (Web Service) por medio de NuSoap.

* La distribucion del codigo es totalmente gratuita y no tiene ningun tipo de restriccion.

* Se agradece que mantengan la fuente del mismo.

*/ $sPais = "argentina"; // Nombre del pais que queremos el listado de localidades

// Inclusion de la libreria nusoap (la que contendra toda la conexión con el servidor // require_once('lib/nusoap.php');

$oSoapClient = new soapclient('http://live.capescience.com/wsdl/GlobalWeather.wsdl', true);

if ($sError = $oSoapClient->getError()) {

echo "No se pudo realizar la operación [" . $sError . "]";

die();

}

$aParametros = array("country" => $sPais);

$respuesta = $oSoapClient->call("searchByCountry", $aParametros);

// Existe alguna falla en el servicio? if ($oSoapClient->fault) { // Si

echo 'No se pudo completar la operación';

die();

} else { // No

$sError = $oSoapClient->getError();

// Hay algun error ?

if ($sError) { // Si

echo 'Error:' . $sError;

die();

}

<html>

<body>

<:tr>

<td colspan="2"><div align="center">Seleccione una localidad</div></td>

</tr>

<tr>

</tr>

<tr>

<td>Localidad:</td>

$aElemento)

echo "<option value='".$aElemento["wmo"]."'>".$aElemento["name"]."</option>";

</select></td>

</tr>

<tr>

</tr>

<tr>

</td>

</tr>

</table>

</form>

</body>

</html>

Web Services en PHP - Parte VII

2009-11-20T15:42:00.000-08:00

Comenzamos a programar!

Como mencione anteriormente he dividido la aplicación de prueba del Web Service en dos (2) archivos, uno que mostrara todas las localidades donde existen pronósticos (seleccionarLocalidad.php) y otro que mostrara el pronóstico para la localidad seleccionada (mostrarPronostico.php)

Veamos como consumimos un web service (searchByCountry):

En el código se han eliminado las comprobaciones de errores para poder facilitar la lectura de los pasos. Veamos cuales son los pasos para consumir un servicio web desde PHP:

require_once(“lib/nusoap.php”);

Debemos incluir la librería NuSOAP. En este ejemplo asumimos que el directorio donde se encuentra el archivo nusoap.php esta ubicado en el subdirectorio lib (a partir de donde esta nuestro script).

$oSoapClient = new soapclient('http://live.capescience.com/wsdl/GlobalWeather.wsdl', true);

Debemos instanciar la clase soapclient, ya que en esta ocasión utilizaremos solo el cliente que nos provee NuSOAP. Los parámetros enviados son la ubicación del documento WSDL y true como segundo parametro (este último parámetro indica que el primer documento es un WSDL) .

Definimos un array con el país para el cual se quieren obtener las localidades que tienen pronósticos disponibles. Volviendo al documento WSDL podemos ver que la variable que debemos enviar es “country” y que es del tipo string

$aParametros = array("country" => "argentina");

280. <message name="searchByCountry">

281. <part name="country" type="xsd:string"/>

282. </message>

$aRespuesta = $oSoapClient->call("searchByCountry", $aParametros);

Llamamos al método call del objeto soapclient. Al mismo le pasamos como parámetro el nombre del método que queremos ejecutar en el web service (searchByCountry) y los parámetros ($aParametros). En nuestra variable $aRespuesta tenemos un array con la respuesta del Web Service. Este array tiene el formato descripto en “ArrayOfStation” (el cual fue visto anteriormente). Es decir podemos acceder a las variables descriptas en ArrayOfStation de la siguiente manera: $aRespuesta[“wmo”], $aRespuesta[“elevation”], $aRespuesta[“name”], etc.

Ahora que ya conocemos c&oacte;mo sería el procedimiento para consumir un Web Service, veamos un poco más en profundidad los métodos de soapclient que utilizamos:

Al crear una instancia de soapclient, existen varios parámetros que podemos enviar para su creación:

$oSoapClient = new soapclient(

<url donde se encuentra el web service o WSDL>,

[<booleana indicando si el primer parámetro es un WSDL>],

[<entero con el Portéame>],

[<cadena proxyHost>],

[<cadena proxyPort>],

[<cadena nombre de usuario>],

[<cadena password>],

[<entero con el timeout de la conexión>],

[<entero con el timeout de la respuesta>]);

Solo el primer parámetro es necesario (la ubicación del Web Service o del documento WSDL del Web Service), todos los demás son opcionales.

Al ejecutar el Web Service, existen varios parámetros que podemos enviar al método:

call( <método que queremos ejecutar en el servidor>,

[<un array asociativo con los parámetros que debemos enviar (si existen)>],

[<cadena con el espacio de nombres (namespace)>],

[<cadena con el valor de la acción SOAP>],

[<booleana indicando si esta presente los valores de SOAPVAL en los headers>],

[<booleana la cual ya no se utiliza>],

[<cadena con el style a usar cuando se realiza la serialización de los parametros>],

[<cadena que puede ser "encoded" o "literal" utilizada para serialización de los parametros>]);

Cómo vemos existen muchos más parametros de los que habiamos utilizado, pero como exigen un conocimiento más profundo sobre los Web Services los cuales escapan a los alcances de este artículo no los trateremos aquí.

Web Services en PHP - Parte VI

2009-11-20T15:30:00.000-08:00

¿Como lo usar NuSOAP?

Para responder a esta pregunta no hay nada mejor que un ejemplo de utilización de NuSOAP, el cual nos ayudará también a terminar de ver los conceptos mencionados anteriormente (SOAP, WSDL, etc.).

Decidí ir a la página de XMethods y buscar algún servicio que pueda ser aplicable por personas de todo el mundo, y que no esté limitado a los Estados Unidos. Buscando entre gran cantidad de Web Services de Cotizaciones, o datos específicos de los Estados Unidos, encontré uno que podía ser implementado en cualquier país, y era ni más ni menos que los datos del clima para todo el mundo. Este Web Service tiene 9 métodos que podemos utilizar (todos ellos se encuentran definidos en el archivo WSDL que se encuentra en http://live.capescience.com/wsdl/GlobalWeather.wsdl Los métodos son: getStation(), isValidCode(), listCountries(), searchByCode(), searchByCountry(), searchByLocation(), searchByName(), searchByRegion(), getWeatherReport().

Para el ejemplo solo utilizare el método searchByCountry() y getWeatherReport().

En el ejemplo existen dos archivos:

seleccionarLocalidad.php: el cual nos permitirá seleccionar una localidad dado un país (el país esta dado por el valor de la variable $sPais). Este archivo PHP utiliza el método del Web Service searchByCountry()

mostrarPronostico.php: el cual mostrara el pronóstico para la localidad seleccionada. Este archivo PHP utiliza el método del Web Service getWeatherReport().

Si queremos ver un listado de los servicios publicados podemos ir a esta página: CapeScience

En esta página nos permiten probar los métodos de los Web Services en línea, sin necesidad de un cliente SOAP, esto nos es de utilidad principalmente para ver como funciona cada uno de los métodos.

Como mencione anteriormente, toda la información del Web Service se encuentra definida dentro del documento WSDL, para este Web service se encuentra definida en CapeScience.

Este documento en particular tiene 425 líneas, por lo que la lectura del mismo es bastante tediosa.

No voy a explicar todo el archivo WSDL, sino que simplemente me detendré en las líneas que son de importancia para nuestra aplicación (las que hacen referencia a los metodos searchByCountry() y getWeatherReport() ). Ahora veamos donde se encuentran las definiciones de los métodos dentro del archivo:

Mensajes de searchByCountry: entre las lineas 277 a 282 podemos apreciar que se encuentra lo siguiente:

277. %lt;message name="searchByCountryResponse">

278. <part name="return" type="xsd1:ArrayOfStation"/>
279. </message>
280. <message name="searchByCountry">
281. <part name="country" type="xsd:string">
282. </message>

SearchByCountry: comencemos por la línea 280 y dejaremos para después las líneas 277 a 279.

280. <message name="searchByCountry">

En esta línea se indica que existe un método llamado searchByCountry, que es el método que estábamos buscando.

281. <part name="country" type="xsd:string"/>

Aquí se define que existe un parámetro para dicho método que se llama “country” (país) y es del tipo string.

282. </message>

Fin del método seachByCountry

Ejemplo de un mensaje real con el parámetro country seteado en “argentina”:

<nu:searchByCountry>

<country xsi:type="xsd:string">argentina</country>
</nu:searchByCountry>

SearchByCountryResponse: Ahora analicemos el método searchByCountryResponse, como su nombre indica, es la respuesta al metodo searchByCountry. Es decir cuando invocamos a searchByCountry, el servidor nos responderá con un mensaje con el formato de searchByCountryResponse. Las respuestas, generalmente, tienen anexado al final Response al nombre del método (esto se epecifica en el portType).

277. <message name="searchByCountryResponse">
Esta línea nos indica que es una respuesta al método searchByCountry.

278. <part name="return" type="xsd1:ArrayOfStation"/>

El método nos devuelve una variable “return” la cual es del tipo ArrayOfSation. Como vimos anteriormente, los documentos WSDL pueden definir sus propios tipos de datos, ArrayOfStation es un tipo de datos definido en este WSDL. Ver más adelante la definición del tipo de datos ArrayOfStation.

279. </message>

Fin del método searchByCountryResponse.

Como vimos anteriormente se hace referencia a un ArrayOfStation, para ver de que se trata esto debemos buscar este tipo de datos dentro del archivo WSDL. En las líneas comprendidas ente 148 y 157, podemos ver que se define este tipo de datos.

148. <xsd:complexType name="ArrayOfStation">

149. <xsd:complexContent>
150. <xsd:restriction base="SOAP-ENC:Array">
151. <xsd:sequence>
152. <xsd:element maxOccurs="unbounded" minOccurs="0" name="item" type="xsd1:Station"/>
153. </xsd:sequence>
154. <xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="xsd1:Station[]"/>
155. </xsd:restriction>
156. </xsd:complexContent>
157. </xsd:complexType>

148. <xsd:complexType name="ArrayOfStation">

En esta línea podemos ver que se define un tipo de datos complejo (complexType) con el nombre de “ArrayOfStation”, el tipo de datos que buscábamos.

149. <xsd:complexContent>

150. <xsd:restriction base="SOAP-ENC:Array">
151. <xsd:sequence>

Indicamos que es un elemento complejo (array).

152. <xsd:element maxOccurs="unbounded" minOccurs="0" name="item" type="xsd1:Station"/>

Esta línea es la que más nos interesa, ya que se indica precisamente como esta compuesto el array. Nos dice que tiene un mínimo de ocurrencias de 0 (MinOccurs=” 0” ), es decir, que puede no tener elementos. Un máximo de ocurrencias no limitado (maxOccurs=”unbounded”), es decir que podemos tener todos los elementos que queramos. Y al finalizar nos indica el tipo de datos del array, que es “Station”. Por desgracia ahora tenemos que ver que tipo de datos es Station. Como podemos ver un dato se define a partir de otro, hasta llegar a los tipos de datos básicos.

153. </xsd:sequence>
Se cierran los tags anteriormente abiertos.

154. <xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="xsd1:Station[]"/>

Terminamos de definir el array.

155. </xsd:restriction>
156. </xsd:complexContent>
157. </xsd:complexType>

Se cierran los demás tags que fueron abiertos.

Nos quedaba pendiente definir el tipo de datos “Station”, nuevamente, al buscar en el código encontramos entre las líneas 134 a 147 la definición de este tipo de datos.

134. <xsd:complexType name="Station">

135. <xsd:sequence>
136. <xsd:element maxOccurs="1" minOccurs="1" name="icao" nillable="true" type="xsd:string"/>
137. < xsd:element maxOccurs="1" minOccurs="1" name="wmo" nillable="true" type="xsd:string"/>

138. < xsd:element maxOccurs="1" minOccurs="1" name="iata" nillable="true" type="xsd:string"/>

139. < xsd:element maxOccurs="1" minOccurs="1" name="elevation" type="xsd:double"/>

140. < xsd:element maxOccurs="1" minOccurs="1" name="latitude" type="xsd:double"/>

141. < xsd:element maxOccurs="1" minOccurs="1" name="longitude" type="xsd:double"/>

142. < xsd:element maxOccurs="1" minOccurs="1" name="name" nillable="true" type="xsd:string"/>

143. < xsd:element maxOccurs="1" minOccurs="1" name="region" nillable="true" type="xsd:string"/>

144. < xsd:element maxOccurs="1" minOccurs="1" name="country" nillable="true" type="xsd:string"/>

145. <xsd:element maxOccurs="1" minOccurs="1" name="string" nillable="true" type="xsd:string"/>

146. </xsd:sequence>
147. </xsd:complexType>

134. <xsd:complexType name="Station">
Se define que comienza el tipo de datos complejo Station.

135. <xsd:sequence>
Indicamos que comenzamos con la definición del tipo secuencia (es decir que todos los elementos que se definen dentro están incluidos en el tipo de datos Station). Existen otro tipo que no es secuencia (sequence), y se llama choice (elección), en el cual se selecciona entre uno de los elementos dentro definidos (aquellos comprendidos entre y ).

136. <xsd:element maxOccurs="1" minOccurs="1" name="icao" nillable="true" type="xsd:string"/>

137. <xsd:element maxOccurs="1" minOccurs="1" name="wmo" nillable="true" type="xsd:string"/>
138. <xsd:element maxOccurs="1" minOccurs="1" name="iata" nillable="true" type="xsd:string"/>
Se definen 3 elementos los cuales son del tipo string, dichos elementos son: icao, wmo, e iata.

139. <xsd:element maxOccurs="1" minOccurs="1" name="elevation" type="xsd:double"/>

140. <xsd:element maxOccurs="1" minOccurs="1" name="latitude" type="xsd:double"/>
141. <xsd:element maxOccurs="1" minOccurs="1" name="longitude" type="xsd:double"/>

Se definen otros 3 elementos, en este caso son del tipo double. Estos son: elevation, latitude, y longitude.

142. <xsd:element maxOccurs="1" minOccurs="1" name="name" nillable="true" type="xsd:string"/>

143. <xsd:element maxOccurs="1" minOccurs="1" name="region" nillable="true" type="xsd:string"/>
144. <xsd:element maxOccurs="1" minOccurs="1" name="country" nillable="true" type="xsd:string"/>
145. <xsd:element maxOccurs="1" minOccurs="1" name="string" nillable="true" type="xsd:string"/>
Se definen los últimos 4 elementos del tipo string. Los elementos aquí definidos son: name, region, country, y string.

146. </xsd:sequence>

147. </xsd:complexType>
Cierre de los tags abiertos anteriormente.

Veamos un ejemplo de respuesta:

<return xsi:type="cc1:ArrayOfStation" SOAP-ENC:arrayType="cc1:Station[86]">

<item xsi:type="cc1:Station">
    <icao xsi:type="xsd:string">SARS</icao>
    <wmo xsi:type="xsd:string">87149</wmo>
    <iata xsi:nil="true"/>
    <elevation xsi:type="xsd:double">91.0</elevation>
    <latitude xsi:type="xsd:double">-26.817</latitude>
    <longitude xsi:type="xsd:double">-60.45</longitude>
    <name xsi:type="xsd:string">Presidencia Roque Saenz Pena Aerodrome</name>
    <region xsi:nil="true"/>
    <country xsi:type="xsd:string">Argentina </country>
    <string xsi:type="xsd:string">SARS - Presidencia Roque Saenz Pena Aerodrome, Argentina
    -26.817'S -60.45'W 91m</string>
    </item>
<item xsi:type="cc1:Station">
</return>

Para aclarar el tipo de estructura de ArrayOfStation usaremos analogías con otros lenguajes de programación:

// Delphi //

Station = record

icao : String;

wmo : String;

iata : String;

elevation : String;

latitude : String;

longitude : String;

name : String;

region : String;

country : String;

string_ : String;

end;

ArrayOfSation : array of Station;

// C# //

struct Station

{

String icao;

String wmo;

String iata;

String elevation;

String latitude;

String longitude;

String name;

String region;

String country;

String string_;

}

Station[] ArrayOfStation;

Como vemos no es fácil seguir todo lo que esta definido dentro de un documento WSDL, por suerte muchas veces no nos tenemos que preocupar por todo esto ya que los mismos sitios donde se encuentran alojados los Web Services nos proveen de la información necesaria sin necesidad de tener que recurrir a ver los archivos WSDL. También existen aplicaciones como son Altova XMLSPY que nos proveen de la información de manera gráfica

Web Services en PHP - Parte V

2009-11-20T12:30:00.000-08:00

¿Que es NuSOAP?

NuSOAP es un kit de herramientas (ToolKit) para desarrollar Web Services bajo el lenguaje PHP. Está compuesto por una serie de clases que nos harán mucho más fácil el desarrollo de Web Services. Provee soporte para el desarrollo de clientes (aquellos que consumen los Web Services) y de servidores (aquellos que los proveen). NuSOAP está basado en SOAP 1.1, WSDL 1.1 y HTTP 1.0/1.1

¿NuSOAP es el único soporte para Web Services en PHP?

No, no es el único, existen otros, pero es uno de los que están en una fase de desarrollo mucho más avanzada. Sin ir más lejos, PHP a partir de su versión 5 comienza a dar soporte para SOAP, pero aún está en fase experimental.

¿Por qué NuSOAP y no otro?

1.Está en una fase madura de desarrollo.

2.No necesita módulos adicionales.

3.Es muy fácil su instalación y uso

¿Cómo instalo NuSOAP?

La instalación es bastante sencilla, sólo basta ir a la pagina en sourceforge de NuSOAP http://sourceforge.net/projects/nusoap/ y bajar el archivo comprimido (es un .zip).

Lo descomprimimos en un directorio de nuestro servidor web (como puede ser /lib que es el directorio por default), y listo, ya podemos hacer uso de NuSOAP.

Web Services en PHP - Parte IV

2009-11-20T12:26:00.000-08:00

Historia de los Web Services

Los Servicios Web surgieron ante una necesidad de estandarizar la comunicación entre distintas plataformas (PC, Mainframe, Mac, etc.) y lenguajes de programación (PHP, C#, Java, etc.).

Anteriormente se habían realizado intentos de crear estándares pero fracasaron o no tuvieron el suficiente éxito, algunos de ellos son DCOM y CORBA, por ser dependientes de la implementación del vendedor DCOM - Microsoft, y CORBA - ORB (a pesar que CORBA de múltiples vendedores pueden operar entre si, hay ciertas limitaciones para aplicaciones de niveles más altos en los cuales se necesite seguridad o administración de transacciones).

Otro gran problema es que se hacía uso de RPC (Remote Procedure Call) para realizar la comunicación entre diferentes nodos. Esto, además de presentar ciertos problemas de seguridad, tiene la desventaja de que su implementación en un ambiente como es Internet, es casi imposible (muchos firewalls bloquean este tipo de mensajes, lo que hace prácticamente imposible a dos computadoras conectadas por Internet comunicarse).

Los Web Services surgieron para finalmente poder lograr la tan esperada comunicación entre diferentes plataformas. En la actualidad muchos sistemas legacy están pasando a ser web services.

Es por esto que en 1999 se comenzó a plantear un nuevo estándar, el cual terminaría utilizando XML, SOAP, WSDL, y UDDI.

¿Los Web services pueden ser solo utilizados con HTTP?

A pesar de mucho limitar el uso de los Web services al protocolo HTTP, los Web services no fueron pensados para un protocolo en particular, es decir, nada nos impide utilizar SOAP sobre algún otro protocolo de Internet (SMTP, FTP, etc.).

Se utiliza principalmente HTTP por ser un protocolo ampliamente difundido y que se encuentra menos restringido por firewalls (generalmente se bloquean puertos como el FTP, pero el HTTP es muy probable que no este bloqueado).

Web Services en PHP - Parte III

2009-11-20T07:49:00.000-08:00

WSDL - Web Services Description Language

Es un protocolo basado en XML que describe los accesos al Web Service. Podriamos decir que es el manual de operación del web service, porque nos indica cuales son las interfaces que provee el Servicio web y los tipos de datos necesarios para la utilización del mismo.

Veamos un ejemplo de un documento WSDL:

<?xml version="1.0">

</definitions>

Explicación del código anterior:

<?xml version="1.0"> Este es otro documento XML, es por esto que debe comenzar con el tag <?xml .. ?>

<definitions> Comienzo del documento, este tag agrupa a todos los demás.

<types> Se definen los tipos de datos utilizados en el Web Service.

</types> Fin de la definición de tipos.

<message> Se definen los métodos y parámetros para realizar la operación. Cada message puede consistir en una o más partes (parámetros).

</message> Fin de la definición de los parámetros.

<portType> Esta sección es la más importante, ya que se definen las operaciones que pueden ser realizadas, y los mensajes que involucran (por ejemplo el mensaje de petición y el de respuesta).

</portType> Fin de la definición de las operaciones y mensajes.

<binding> Se definen el formato del mensaje y detalles del protocolo para cada portType.

</binding> Fin de la definición del formato del mensaje y detalles del protocolo para cada PortType.

</definitions> Fin del documento WSDL

UDDI - Universal Discovery Description and Integration

Es un modelo de directorios para Web Services. Es una especificación para mantener directorios estandarizados de información acerca de los Web Services, sus capacidades, ubicación, y requerimientos en un formato reconocido universalmente. UDDI utiliza WSDL para describir las interfaces de los Web Services.

Es un lugar en el cual podemos buscar cuales son los Servicios web disponibles, una especie de directorio en el cual podemos encontrar los Web Services publicados y publicar los Web Services que desarrollemos.

Heroes 5 Temporada: Redemption Capitulo 10 Brother´s keeper

2009-11-17T05:39:00.001-08:00

Web Services en PHP - Parte II

2009-11-16T14:35:00.000-08:00

SOAP: Simple Object Access Protocol

Es un protocolo que permite la comunicación entre aplicaciones a través de mensajes por medio de Internet. Es independiente de la plataforma, y del lenguaje. Esta basado en XML y es la base principal de los Web Services. Los mensajes SOAP son documento XML propiamente dicho, pero esto lo veremos más adelante cuando veamos un ejemplo de un mensaje SOAP.

Veamos como es la estructura básica del protocolo y la correspondiente explicación:

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

Soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header>

...

</soap:Header>

<soap:Body>

...

<soap:Fault>

...

</soap:Fault>

</soap:Body>

</soap:Envelope>

Explicación del código anterior:

<?xml version="1.0"?>

Como podemos ver en esta linea SOAP es un documento XML, y como tal, debe comenzar con el tag <?xml….?> y la versión correspondiente.

<soap:Envelope

Aquí se indica que comienza el envelope (sobre) del mensaje

xmlns:soap = "http://www.w3.org/2001/12/soap-envelope"

Un mensaje SOAP debe contener siempre un elemento envelope asociado con el namespace (espacio de nombres) http://www.w3.org/2001/12/soap-envelope

Soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

En esta línea lo que se hace es indicar donde se encuentran definidos los tipos de datos utilizados en el documento.

<soap:Header>

Esta línea indica el comienzo del Header (encabezado). En esta sección se incluye información específica del mensaje, como puede ser la autenticación.

</soap:Header>

Como todo documento XML los tags que son abiertos deben ser cerrados, esta línea indica la finalización del Header (encabezado).

<soap:Body>

Aquí comienza el cuerpo del mensaje, en esta sección se incorpora toda la información necesaria para el nodo final. Por ejemplo, los parámetros para la ejecución, o la respuesta a una petición.

<soap:Fault>

Cualquier tipo de fallo que se produzca será notificado en esta sección. La cual esta contenida dentro del cuerpo del mensaje.

</soap:Fault>

Cierre de la sección Fault.

</soap:Body>

Indica el final del cuerpo del mensaje.

</soap:Envelope>

Fin del mensaje SOAP.

Web Services en PHP - Parte I

2009-11-16T06:29:00.000-08:00

Explicamos qué son los servicios web y cuales son los elementos por los que están compuestos.

El presente artículo esta dirigido a las personas que ya poseen conocimientos sobre Internet y programación y quieren comenzar a conocer el mundo de los web services (servicios web).

¿Cómo esta estructurado el artículo?

Comenzaremos dando una introducción a lo que son los Web Services (Servicios Web), luego definiremos los elementos que lo componen, y al finalizar veremos un ejemplo de cómo utilizar un web service por medio de NuSOAP, para el cual utilizaremos dos archivos PHP.

Introducción:

Antes de comenzar explicando NuSoap, creo que es conveniente realizar una introducción a lo que son los Servicios Web, y para esto debemos comenzar con la definición de Web Service.

Web Service:

Es un sistema software diseñado para soportar la interoperabilidad máquina - máquina a través de una red. Este tiene una interfaz descripta en un formato que puede ser procesado por una máquina (específicamente WSDL, que veremos más adelante). Otros sistemas interactúan con el Web service utilizando mensajes SOAP los cuales se encuentran establecidos previamente.

Entonces podríamos decir que un Web Service es una comunicación por medio de mensajes SOAP (son mensajes especiales que más adelante veremos detenidamente) entre diferentes equipos a través de una red.

Ahora pasaremos a definir los elementos que componen a los Web Services, para luego ver como ellos estan interrelacionados.

¿Qué es XML, SOAP, WSDL, UDDI?

Para conocer cómo se realiza el intercambio de mensajes en los Web Services debemos primero saber cuales son los elementos fundamentales que lo componen. Estos son el XML, SOAP, WSDL, y UDDI.

XML - eXtensible Markup Language:

Es un subconjunto simplificado del SGML el cual fue diseñado principalmente para documentos Web. Deja a los diseñadores crear sus propias “etiquetas” o "tags" (Ej: <libro>), habilitando la definición, transmisión, validación, y la interpretación de datos entre aplicaciones y entre organizaciones. Un punto que considero que es importante aclarar es que el HTML y el XML tienen funciones diferentes. El HTML tiene por objeto mostrar información, mientras que el XML se ocupa de la información propiamente dicha (el contenido). Este concepto es importante tenerlo en cuenta, ya que muchas personas al escuchar sobre XML piensan que es el sucesor de HTML.

Ejemplo de un documento XML sobre información de autos:
<?xml version="1.0" encoding="UTF-8"?>
<vehiculos>
<coche>
<marca>Toyota</marca>
<modelo>Corolla</modelo>
<fechaCompra>2002</fechaCompra>
</coche>
<coche>
<marca>Honda</marca>
<modelo>Civic</modelo>
<fechaCompra>2003</fechaCompra>
</coche>
</vehiculos>

Seguramente este tipo de archivos no sea una novedad para la mayoría de los que lean este artículo, ya que muchos documentos en Internet están en formato XML. Igualmente explicaremos brevemente las secciones del mismo:

<?xml version="1.0" encoding="UTF-8"?>

Todo documento XML debe comenzar indicando que es un documento XML, la versión del mismo y su codificación. Es por eso que se utiliza el tag <?xml .... ?> . Todos los elementos a partir de aquí son definidos por el usuario.

<vehiculos>

Luego se indica un tag raiz (<vehiculos>) el cual contendrá a los demás elementos. Es como en HTML el tag <HTML> .. </HTML>, que dentro de el se encuentran los demás tags. Se lo conoce generalmente como root del documento.

<coche>

Luego definimos un tag <coche> el cual contendrá un coche en particular (en este caso solo incorpore 3 características de un coche: marca, modelo, y fecha de compra).

<marca>Toyota</marca>
<modelo>Corolla</modelo>
<fechaCompra>2002</fechaCompra>

Se definen 3 tags (marca, modelo, y fechaCompra), los cuales contienen los datos para un coche en particular.

<vehiculos>
<coche>
<marca>..</marca>
<modelo>..</modelo>
<fechaCompra>..</fechaCompra>
</coche>
</vehiculos>

En el documento podemos apreciar que todos los tags que son abiertos <marca> deben ser cerrados </marca>. Esto es una exigencia del XML.

Se pueden anidar tags <coche><marca></marca>…..</coche>. Marca esta dentro del tag coche. El XML provee muchas otras posibilidades como puede ser que las etiquetas tengan atributos (<coche color="rojo">..</coche>), pero no nos detendremos en ellas ya que la idea es simplemente ofrecer los conceptos básicos para conocer de que se trata el mundo de los Web Services.

Principios de Diseño de Base de Datos - Parte V

2009-11-14T07:47:00.000-08:00

Una tabla temporal existe mientras dure la conexión a MySQL. Cuando se interrumpe la conexión MySQL remueve automáticamente la tabla y libera el espacio que ésta usaba. Nosotros podemos por supuesto eliminar esta tabla mientras estamos conectados a MySQL. Si una tabla nombrada tabla_temp ya existe en nuestra base de datos al momento de crear una tabla temporal con el mismo nombre, la tabla temporal oculta a la tabla no temporal.

MySQL también permite especificar que una tabla temporal sea creada en memoria si dicha tabla se declara del tipo HEAP:

CREATE TEMPORARY TABLE tabla_temp

(

campo1 tipoDato,

campo2 tipoDeDato,

...

) TYPE = HEAP;

Ya que las tablas del tipo HEAP son almacenadas en memoria, las consultas sobre estas tablas son ejecutadas mucho más rápido que en las tablas en disco no temporales. Sin embargo las tablas HEAP son ligeramente diferentes de una tabla normal y tienen algunas limitaciones propias.

Como en las sugerencias previas, lo único que nos queda es probar si con las tablas temporales nuestras consultas se ejecutan más rápidamente que usando la tabla que contiene una gran cantidad de datos. Si los datos están bien indexados puede que las tablas temporales no nos sean de mucha utilidad.

Usar una versión reciente de MySQL

La recomendación es simple y concreta, siempre que esté en nuestras manos, debemos usar la versión más reciente de MySQL que se encuentre disponible. Además de que las nuevas versiones frecuentemente incluyen muchas mejoras, cada vez son más estables y más rápidas. De esta manera, a la vez que sacamos provecho de las nuevas características incorporadas en MySQL, veremos significativos incrementos en la eficiencia de nuestro servidor de bases de datos.

Consideraciones finales

El último paso del diseño de la base de datos es adoptar determinadas convenciones de nombres. Aunque MySQL es muy flexible en cuanto a la forma de asignar nombre a las bases de datos, tablas y columnas, he aquí algunas reglas que es conveniente observar:

* Utilizar caracteres alfanuméricos.

* Limitar los nombres a menos de 64 caracteres (es una restricción de MySQL).

* Utilizar el guión bajo (_) para separar palabras.

* Utilizar palabras en minúsculas (esto es más una preferencia personal que una regla).

* Los nombres de las tablas deberían ir en plural y los nombres de las columnas en singular (es igual una preferencia personal).

* Utilizar las letras ID en las columnas de clave primaria y foránea.

* En una tabla, colocar primero la clave primaria seguida de las claves foráneas.

* Los nombres de los campos deben ser descriptivos de su contenido.

* Los nombres de los campos deben ser unívocos entre tablas, excepción hecha de las claves.

Los puntos anteriores corresponden muchos de ellos a preferencias personales, más que a reglas que debamos de cumplir, y en consecuencia muchos de ellos pueden ser pasados por alto, sin embargo, lo más importante es que la nomenclatura utilizada en nuestras bases de datos sea coherente y consistente con el fin de minimizar la posibilidad de errores al momento de crear una aplicación de bases de datos.

Principios de Diseño de Base de Datos - Parte IV

2009-11-14T07:42:00.000-08:00

A continuación se dan algunos consejos que nos ayudarán a elegir un tipo de dato adecuado para nuestras tablas:

* Identificar si una columna debe ser de tipo texto, numérico o de fecha.

Esto suele ser un paso demasiado sencillo. Valores eminentemente numéricos como códigos postales o cantidades monetarias deben tratarse como campos de texto si decidimos incluir sus signos de puntuación, pero obtendremos mejores resultados si los almacenamos como números y solucionamos la cuestión del formato de alguna otra forma.

* Elegir el subtipo más apropiado para cada columna.

Los campos de longitud fija (como CHAR) son generalmente más rápidos que los de longitud variable (como VARCHAR), aunque ocupan más espacio en disco.

El tamaño de cada campo debe restringirse al mínimo en función de cuál pudiera ser la entrada más grande. Por ejemplo, si el valor en una columna de tipo entero es menor de mil, lo mejor es configurar esta columna como un SMALLINT de tres dígitos sin signo (lo que permite exactamente 999 valores distintos).

* Configurar la longitud máxima para las columnas de texto y numéricas, así como otros atributos.

Puede que nosotros tengamos preferencias distintas, pero el factor más importante es siempre ajustar al máximo la información de cada campo en lugar de usar siempre tipos TEXT e INT genéricos (e ineficientes).

Utilizar índices apropiadamente

Los índices son un sistema especial que utilizan las bases de datos para mejorar su rendimiento global. Al definir índices en las columnas de una tabla, se le indica a MySQL que preste atención especial a dichas columnas.

MySQL permite definir hasta 32 índices por cada tabla y cada índice puede incorporar hasta 16 columnas. Aunque un índice de varias columnas puede no resultar de utilidad obvia a primera vista, lo cierto es que resulta muy útil a la hora de realizar búsquedas frecuentes sobre un mismo conjunto de columnas.

Dado que los índices hacen que las consultas se ejecuten más rápido, podemos estar incitados a indexar todas las columnas de nuestras tablas. Sin embargo, lo que tenemos que saber es que el usar índices tiene un precio. Cada vez que hacemos un INSERT, UPDATE, REPLACE, o DELETE sobre una tabla, MySQL tiene que actualizar cualquier índice en la tabla para reflejar los cambios en los datos.

¿Así que, cómo decidimos usar índices o no?. La respuesta es "depende". De manera simple, depende que tipo de consultas ejecutamos y que tan frecuentemente lo hacemos, aunque realmente depende de muchas otras cosas.

La razón para tener un índice en una columna es para permitirle a MySQL que ejecute las búsquedas tan rápido como sea posible (y evitar los escaneos completos de tablas). Podemos pensar que un índice contiene una entrada por cada valor único en la columna. En el índice, MySQL debe contar cualquier valor duplicado. Estos valores duplicados decrementan la eficiencia y la utilidad del índice.

Así que antes de indexar una columna, debemos considerar que porcentaje de entradas en la tabla son duplicadas. Si el porcentaje es demasiado alto, seguramente no veremos alguna mejora con el uso de un índice.

Otra cosa a considerar es qué tan frecuentemente los índices serán usados. MySQL puede usar un índice para una columna en particular si dicha columna aparece en la cláusula WHERE en una consulta. Si muy rara vez usamos una columna en una cláusula WHERE, seguramente no tiene mucha sentido indexar dicha columna. De esta manera, probablemente sea más eficiente sufrir el escaneo completo de la tabla las raras ocasiones en que se use esta columna en una consulta, que estar actualizando el índice cada vez que cambien los datos de la tabla.

Ante la duda, no tenemos otra alternativa que probar. Siempre podemos ejecutar algunas pruebas sobre los datos de nuestras tablas con y sin índices para ver como obtenemos los resultados más rápidamente. Lo único a considerar es que las pruebas sean lo más realistas posibles.

Usar consultas REPLACE

Existen ocasiones en las que deseamos insertar un registro a menos de que éste ya se encuentre en la tabla. Si el registro ya existe, lo que quisiéramos hacer es una actualización de los datos. En lugar de escribir el código que cumpla con esta lógica, y tener que ejecutar varias consultas, lo mejor es usar la sentencia REPLACE de MySQL.

Usar tablas temporales

Cuando estamos trabajando con tablas muy grandes, suele suceder que ocasionalmente necesitemos ejecutar algunas consultas sobre un pequeño subconjunto de una gran cantidad de datos. En vez de ejecutar estas consultas sobre la tabla completa y hacer que MySQL encuentre cada vez los pocos registros que necesitamos, puede ser mucho más rápido seleccionar dichos registros en una tabla temporal y entonces ejecutar nuestras consultas sobre esta tabla.

Crear una tabla temporal es tan sencillo como agregar la palabra TEMPORARY a una sentencia típica CREATE TABLE:

CREATE TEMPORARY TABLE tabla_temp

(

campo1 tipoDato,

campo2 tipoDeDato,

);

Principios de Diseño de Base de Datos - Parte III

2009-11-14T07:29:00.000-08:00

Mucha gente nueva en los sistemas de bases de datos relacionales no sabe en verdad lo que significa "relacional" en RDBMS (Relational Database Management System). En términos simples, grupos parecidos de información son almacenados en distintas tablas que luego pueden ser "juntadas" (relacionadas) basándose en los datos que tengan en común. Desafortunadamente esto suena bastante académico y vago, sin embargo, en nuestra base de datos de CDs podemos ejemplificar una situación concreta en la que veremos cómo normalizar los datos.

El darnos cuenta de que cada lista de CDs tiene un conjunto fijo de atributos (título, artista, año, género) y un conjunto variable de atributos (el número de pistas) nos da una idea de cómo dividir los datos en múltiples tablas que luego podamos relacionar entre sí. Podemos crear una tabla que contenga una lista de todos los álbumes y sus atributos fijos y otra que contenga una lista de todas las pista de esos álbumes. De esta forma, en vez de pensar en forma horizontal (como con la hoja de cálculo), pensamos en forma vertical y dejamos una estructura de tablas como la que se muestra a continuación.

CREATE TABLE album (

id_album INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,

titulo VARCHAR(80) NOT NULL );

CREATE TABLE pista (

id_album INTEGER NOT NULL,

numero INTEGER NOT NULL,

titulo VARCHAR(80) NOT NULL );

El identificador de álbum (id_album) es lo que relaciona las distintas pistas de un álbum dado. El campo id_album en la tabla pista coincide con el campo id_album en la tabla album, de tal manera que para obtener una lista de todas las pistas de un álbum dado, podríamos realizar una consulta como esta:

SELECT pista.numero, pista.nombre FROM album, pista

WHERE album.titulo = "El titulo del album"

AND album.id_album = pista.id_album

Esta estructura es a la vez flexible y eficiente. La flexibilidad está en el hecho que podemos agregar datos al sistema posteriormente sin tener que rescribir lo que ya tenemos. Por ejemplo, si quisiéramos agregar la información de los artistas de cada álbum, lo único que tenemos que hacer es crear una tabla artista que esté relacionada a la tabla album de la misma manera que la tabla pista. Por lo tanto, no tendremos que modificar la estructura de nuestras tablas actuales, simplemente agregar la que hace falta.

La eficiencia se refiere al hecho de que no tenemos duplicación de datos, y tampoco tenemos grandes cantidades de "celdas vacías". De esta manera MySQL no tiene que almacenar más datos de los necesarios, ni gastar recursos al revisar las áreas vacías en nuestras tablas.

El objetivo principal del diseño de bases de datos es generar tablas que modelan los registros en los que guardaremos nuestra información. Es importante que esta información se almacene sin redundancia para que se pueda tener una recuperación rápida y eficiente de los datos. A través de la normalización tratamos de evitar ciertos defectos que nos conduzcan a un mal diseño y que lleven a un procesamiento menos eficaz de los datos.

Podríamos decir que estos son los principales objetivos de la normalización:

* Controlar la redundancia de la información.

* Evitar pérdidas de información.

* Capacidad para representar toda la información.

* Mantener la consistencia de los datos.

Si somos novatos en el ambiente de las bases de datos relacionales pudiéramos pensar que con la normalización nuestros datos tienen una apariencia extraña, sin embargo, esto le permite a MySQL ser muy eficiente al momento de almacenar y recuperar los datos de las tablas, además de que nos da la flexibilidad de crecer y escalar nuestras aplicaciones sin la necesidad de reestructurar una base de datos a cada momento.

Seleccionar el tipo de dato apropiado

Una vez identificadas todas las tablas y columnas que necesita la base de datos, debemos determinar el tipo de dato de cada campo. Existen tres categorías principales que pueden aplicarse prácticamente a cualquier aplicación de bases de datos:

* Texto

* Números

* Fecha y hora

Cada uno de éstos presenta sus propias variantes, por lo que la elección del tipo de dato correcto no sólo influye en el tipo de información que se puede almacenar en cada campo, sino que afecta al rendimiento global de la base de datos.

Principios de Diseño de Base de Datos - Parte II

2009-11-13T14:35:00.000-08:00

Obtener todas las columnas de una tabla es simplemente lo más conveniente que podemos hacer cuando no estamos seguros de qué campos necesitamos. Sin embargo, a medida que las tablas crecen y cambian, esto puede convertirse en un problema de rendimiento. A la larga es mucho mejor tardarnos un tiempo extra después de nuestro desarrollo inicial y decidir exactamente qué es lo que necesitamos en nuestras búsquedas. En concreto, es mucho mejor especificar las columnas de forma explícita:

SELECT nombre, precio, descripcion FROM productos;

Esto se relaciona con un punto que tiene que ver más con el mantenimiento del código que con el rendimiento. La mayoría de los lenguajes de programación (Perl, Python, PHP, Java, etc) nos permiten acceder a los resultados de una consulta por los nombres de los campos y por su posición numérica. Para el ejemplo anterior, podemos acceder al campo 0, o al campo nombre y obtener los mismos resultados.

A la larga es mejor usar los nombres de columnas que sus posiciones numéricas. ¿Por qué? Porque las posiciones relativas de columnas en una tabla o en un resultado de una consulta pueden variar. Por ejemplo, pueden variar en una tabla como resultado de un ALTER TABLE, o bien, cambiarán en una consulta como resultado de que alguien rescriba la búsqueda y se olvide de actualizar la lógica de la aplicación apropiadamente.

Claro está, ¡aún debemos ser cuidadosos cuando cambiemos los nombres de las columnas! Pero si usamos nombres en vez de posiciones numéricas, podemos usar la capacidad de búsqueda y reemplazo de nuestro editor para encontrar el código que hemos de cambiar en caso de que cambie el nombre de una columna.

Normalizar las estructuras de tablas

Si nunca antes hemos oído hablar de la "normalización de datos", no debemos temer. Mientras que la normalización puede parecer un tema complejo, nos podemos beneficiar ampliamente al entender los conceptos más elementales de la normalización.

Una de las formas más fáciles de entender esto es pensar en nuestras tablas como hojas de cálculo. Por ejemplo, si quisiéramos seguir la pista de nuestra colección de CDs en una hoja de cálculo, podríamos diseñar algo parecido a lo que se muestra en la siguiente tabla.

+------------+-------------+--------------+ .. +--------------+

| album | track1 | track2 | track10

+------------+-------------+--------------+ .. +--------------+

|| (Baltimora) | (Opus) | .. | (Al Corley) |

+------------+-------------+--------------+ .. +--------------+

Esto parece razonable. Sin embargo el problema es que el número de pistas que tiene un CD es bastante variable. Esto significa que con este método tendríamos que tener una hoja de cálculo realmente grande para albergar todos los datos, que en los peores casos podrían ser de hasta 20 pistas. Esto en definitiva no es nada bueno.

Uno de los objetivos de una estructura de tabla normalizada es minimizar el número de "celdas vacías". En el caso de la tabla de CDs que estamos tratando, tendríamos muchas de estas celdas si permitiéramos CDs de 20 pistas o más. En el caso de que las listas de campos pueden expandirse "hacia la derecha", como en este ejemplo de los CDs, nos da una pista de que necesitamos dividir los datos en dos o más tablas a las que luego podamos acceder de forma conjunta para obtener los datos que necesitemos.