🚀 go-pugleaf

> > TRANSFORM Max([MiTabla].Value) AS [El Valor] SELECT
> > [MiTabla].ID FROM [MiTabla] GROUP BY [MiTabla].ID
> > PIVOT [MiTabla].Property

> �Qu� hace exactamente la orden?

Sup�n una tabla as�:

MiTabla:

----------------+-----------------+------------------+
ID              |Property         |Value             |
----------------+-----------------+------------------+
Elemento1        Color             Blanco
Elemento1        Material          Madera
Elemento1        Fecha_de_Entrada  23 ago 2001
Elemento2        Color             Rojo
Elemento3        Color             Rojo
Elemento3        Fecha_de_Entrada  25 ago 2001
Elemento3        Prestado_a        Antonio

El Select presentado convierte filas a columnas de forma din�mica
y tiene un resultado as�:

ID        | Color  | Material | Fecha       | Prestado_a
-------------------------------------------------------------
Elemento1 | Blanco | Madera   | 23 ago 2001 |
Elemento2 | Rojo   |          |             |
Elemento3 | Rojo   |          | 25 ago 2001 | Antonio

Esto permite fichar cosas de las que a priori en el momento
del dise�o del software no se conocen las propiedades a fichar.
Dicho de otra forma, es como php con los miembros de las
clases, que son como din�micos, cosa que no se podr�a
hacer en C por la necesidad de definir la clase antes de
compilar. Ficharlo no es lo dif�cil, luego las consultas
se simplifican un mont�n. Llamemos V a la vista transformada.
Hacer
SELECT * FROM V WHERE Color='Rojo' AND Prestado_a='Antonio' 
no es inmediato (aunque a priori lo parezca) en la primera tabla,
porque nuestra intuici�n nos enga�a:
TEndemos a pensar que Color='Rojo' en V es como
Property='Color' AND Value='Rojo' en la primera tabla pero...
SELECT * FROM MiTabla WHERE (Property='Color' AND Value='Rojo')
AND (Property='Prestado_a' ADN Value='Antonio') no dar�
ning�n registro como resultado porque no hay ninguna l�nea
en la primera tabla que _a la vez_ tenga Property='Color'
y Property='Prestado_a' lo que da falso el where all� donde
se analice.

De esta forma, el usuario, con s�lo a�adir una l�nea en
la tabla original, del tipo

("Elemento2", "Origen", "Inglaterra")

fuerza que la siguiente vez que se lee la cl�usula transform
�sta devuelva una columna adicional llamada "Origen" con
valores vac�os para todos los elementos salvo para
el Elemento 2 que tendr� un valor de "Inglaterra" y
las formas de buscar elementos desde c�digo ser�n inmediatas
sin necesidad de a�adir c�digo adicional para b�squedas
complejas.

Es flexibilidad no la he sabido encontrar en MySQL ni
Postgress excepto si mi programa hace uso de las cl�usulas
ALTER TABLE xxx ADD COLUMN kk ttt; o alguna cosa por el
estilo, pero me gusta m�s el transform por la automatizaci�n
(y por tanto ahorro de c�gigo potencialmente lleno de
bugs).

Sobre si es ANSI o no, me suena que s�, pero no estoy seguro,
y me gustar�a saber si alguien sabe si se puede "confiar" en
desarrollar clientes basados en esa cl�usula si se persigue
que las bases contra las que se act�a actualmente se puedan
substituir en el menor tiempo posible por servers con
Linux y alguna base del tipo PG o My.

Gracias.
Xavi.
-- 
Xavier Montero - Digital Sound Items, scp
Tel: 93 589 71 91 - Fax: 93 590 10 96 - Cell: 630 59 01 62
www.dsitelecom.com - xmontero@dsitelecom.com