🚀 go-pugleaf

El viernes, 11 de julio de 2003, a las 22:27 GMT, Horacio Miranda escribi�:

> mysql no tiene funciones o procedimientos almacenados, postgres si, pero creo
> que existe el for en sql :P
> 

Pues yo me he revisado conciencudamente el manual de mysql y no lo he
encontrado. La �nica forma de simular un for que se me ha ocurrido es
crear una tabla con un �nico campo cuyas valores sean 0,1,2,3,4, etc...
y al hacer un SELECT incluirla en FROM. Por ejemplo, sup�n (de hecho era
mi problema) que tienes una tabla con gastos con los siguientes campos:

fecha: cuando se produce el gasto
importe: el importe del gasto
vigencia: el plazo de amortizaci�n del gasto en meses. Por ejemplo, si
te compras una barra de pan est� claro que el plazo de amortizaci�n es
uno (te comes la barra ese d�a y ya est�). Sin embargo, si lo que haces
es pagar la matr�cula de la Universidad lo m�s realista no es achacar
ese gasto al mes de octubre sino al periodo octubre-junio (vigencia=9) o
octubre-septiembre (vigencia=12).

Perfecto. Ahora imagina que quieres hacer una consulta sobre la tabla
que te desglose tus gastos por meses. �Cu�l es el problema? Pues que un
gasto que se amortiza en varios meses es un �nico registro y, sin embargo,
tiene que engrosar el gasto de varios meses. Eso es imposible de hacer
directamente con un SELECT: cada registro s�lo puede sumar una vez (o
ninguna). A m� el �nico modo que se me ha ocurrido para resolverlo (en
vista de que no ve�a el for por ning�n sitio) es algo as�:

SELECT gastos.*
FROM auxiliar,gastos
WHERE
    auxiliar.indice<gastos.vigencia

Evidentemente gastos es la tabla de gastos y auxiliar es esta tabla de
�ndices que digo.

De esto modo, logro que cada registro aparezca exactamente el mismo
n�mero de veces que indica su campo vigencia. Evidentemente esta es una
consulta muy cruda. Habr�a que hacer comprobaciones sobre la fecha,
agruparlo por meses, etc... para obtener la consulta que he propuesto m�s
arriba.

Por cierto, que si cuento todo el problema es por conocer si a alguno se
le ocurre una soluci�n mejor. La pega de esta soluci�n es que la tabla
auxiliar tiene un n�mero determinado de registros. Por ejemplo, 48 (4
a�os). Si la hago as�, la base de datos estar� limitada a que las
amortizaciones sean menores de 4 a�os.

De ah� que empezase el hilo preguntando lo que pregunt�. Al final he
tirado por el camino de en medio. He creado una tabla auxiliar de 48
registros y cada vez que introduzco un nuevo gasto, un script me
comprueba si el plazo de amortizaci�n de ese nuevo gasto es mayor que el
n�mero de registros. Si es as�, aumenta el tama�o de la tabla auxiliar
lo necesario con un for (de bash). No he querido usar php ni perl porque
no s� y adem�s mi objetivo era (y es) hacer las consultas en el SQL que
me provee mysql, para prender el lenguaje SQL.

Una chapucilla que no me acaba de convencer. :(

-- 
Parezco en mi fortuna al Manzanares,
que con agua o sin ella siempre es r�o.
                  --- Tom� de Burguillos ---
   Si     Di�xido de Silicio |        Debian GNU/Linux 
  /  \         (SiO2)        |    Jos� Miguel S�nchez Al�s
 O    O   Mineral de Cuarzo  |  sio2.arr@ba.online.fr | URL #257033