Columna Calculada con indice

Estas tres consultas me dan 1


"Alejandro Mesa" escribió en el
mensaje news:

GenioMaestro,

Chequea el tema "Creating Indexes on Computed Columns" en los BOL. Puede
ser
que como calculas el valor a partir de multiples filas, esto hace que la
funcion sea no determinista. Usa la funcion "objectproperty" para
comprobar
si la funcion es determinista y en caso de ser determinista verifica si es
imprescisa, creo que en ese caso puedes usar la opcion "persisted" cuando
creas la columna y sql server dejara crear un indice.

Creating Indexes on Computed Columns
http://msdn2.microsoft.com/en-us/li...89292.aspx

> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND COTIZACIONES.FECHA
> >> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND .CALCULOS.FECHA_CAL IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC

A proposito, yo no usaria "left join" para comprobar existencia. Usaria el
operador "exists" a cambio. De todas maneras prueba ambas versiones a ver
cual te da mejor resultado. Tambien ve si tener un indice en
[COTIZACIONES]
por [COD_VALOR] ayuda a mejorar el plan de ejecucion.

SELECT TOP 1
c.FECHA
FROM
DBO.COTIZACIONES as a
WHERE
c.COD_VALOR = @entra_valor
and not exists (
select *
from DBO.CALCULOS as b
where
b.COD_VALOR = a.COD_VALOR
and b.FECHA_CAL = a.FECHA
)
ORDER BY
c.FECHA ASC
go


AMB

"GenioMaestro" wrote:

Y además, esta consulta tampoco me la paraleliza, tarda dos o tres
minutos
en darme la select con la columna calculada, porque la está calculando al
vuelo, cada vez que la pido, y con el micro al 50%, claro.

Hay alguna manera de forzar al sql server 2005 para que paralelize una
consulta????



"GenioMaestro" escribió en el mensaje
news:
> Va la funcion:
>
> ALTER FUNCTION [dbo].[FECHA_CAL_INI] (@entra_valor as INT)
> RETURNS DATETIME
> WITH SCHEMABINDING
> BEGIN
>
> RETURN (
> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND COTIZACIONES.FECHA
> >> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND .CALCULOS.FECHA_CAL IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC
> )
> END
>
> Gracias por el interes, Alejandro.
>
>
>
> "Alejandro Mesa" escribió en
> el
> mensaje news:
>> GenioMaestro,
>>
>> Pudieras mostrarnos la funcion?
>>
>>
>> AMB
>>
>> "GenioMaestro" wrote:
>>
>>> Hola:
>>>
>>> He creado una columna calculada en base a una funcion de usuario que
>>> funciona bien, pero es muy lenta.
>>>
>>> Cuando intento crear un indice sobre esa columna sql 2005 me dice:
>>>
>>> Mens. 2709, Nivel 16, Estado 1, Línea 1
>>> La columna 'F_CAL_INI' de tabla 'VALORES' no se puede usar en un
>>> índice
>>> o en
>>> estadísticas, o como una clave de partición, porque tiene acceso a
>>> datos
>>> del
>>> usuario o sistema.
>>>
>>> Alguien puede decirme a que es debido y como solucionarlo???
>>>
>>> Gracias
>>>
>>>
>>>
>
>

GenioMaestro,

Estas tres consultas me dan 1

No comprendo lo que me dices.


AMB

"GenioMaestro" wrote:

Estas tres consultas me dan 1


"Alejandro Mesa" escribió en el
mensaje news:
> GenioMaestro,
>
> Chequea el tema "Creating Indexes on Computed Columns" en los BOL. Puede
> ser
> que como calculas el valor a partir de multiples filas, esto hace que la
> funcion sea no determinista. Usa la funcion "objectproperty" para
> comprobar
> si la funcion es determinista y en caso de ser determinista verifica si es
> imprescisa, creo que en ese caso puedes usar la opcion "persisted" cuando
> creas la columna y sql server dejara crear un indice.
>
> Creating Indexes on Computed Columns
> http://msdn2.microsoft.com/en-us/li...89292.aspx
>
>> > SELECT TOP 1 COTIZACIONES.FECHA
>> > FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
>> > ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND COTIZACIONES.FECHA
>> > > >> > CALCULOS.FECHA_CAL
>> > WHERE COTIZACIONES.COD_VALOR = @entra_valor AND .CALCULOS.FECHA_CAL IS
>> > NULL
>> > ORDER BY COTIZACIONES.FECHA ASC
>
> A proposito, yo no usaria "left join" para comprobar existencia. Usaria el
> operador "exists" a cambio. De todas maneras prueba ambas versiones a ver
> cual te da mejor resultado. Tambien ve si tener un indice en
> [COTIZACIONES]
> por [COD_VALOR] ayuda a mejorar el plan de ejecucion.
>
> SELECT TOP 1
> c.FECHA
> FROM
> DBO.COTIZACIONES as a
> WHERE
> c.COD_VALOR = @entra_valor
> and not exists (
> select *
> from DBO.CALCULOS as b
> where
> b.COD_VALOR = a.COD_VALOR
> and b.FECHA_CAL = a.FECHA
> )
> ORDER BY
> c.FECHA ASC
> go
>
>
> AMB
>
> "GenioMaestro" wrote:
>
>> Y además, esta consulta tampoco me la paraleliza, tarda dos o tres
>> minutos
>> en darme la select con la columna calculada, porque la está calculando al
>> vuelo, cada vez que la pido, y con el micro al 50%, claro.
>>
>> Hay alguna manera de forzar al sql server 2005 para que paralelize una
>> consulta????
>>
>>
>>
>> "GenioMaestro" escribió en el mensaje
>> news:
>> > Va la funcion:
>> >
>> > ALTER FUNCTION [dbo].[FECHA_CAL_INI] (@entra_valor as INT)
>> > RETURNS DATETIME
>> > WITH SCHEMABINDING
>> > BEGIN
>> >
>> > RETURN (
>> > SELECT TOP 1 COTIZACIONES.FECHA
>> > FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
>> > ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND COTIZACIONES.FECHA
>> > > >> > CALCULOS.FECHA_CAL
>> > WHERE COTIZACIONES.COD_VALOR = @entra_valor AND .CALCULOS.FECHA_CAL IS
>> > NULL
>> > ORDER BY COTIZACIONES.FECHA ASC
>> > )
>> > END
>> >
>> > Gracias por el interes, Alejandro.
>> >
>> >
>> >
>> > "Alejandro Mesa" escribió en
>> > el
>> > mensaje news:
>> >> GenioMaestro,
>> >>
>> >> Pudieras mostrarnos la funcion?
>> >>
>> >>
>> >> AMB
>> >>
>> >> "GenioMaestro" wrote:
>> >>
>> >>> Hola:
>> >>>
>> >>> He creado una columna calculada en base a una funcion de usuario que
>> >>> funciona bien, pero es muy lenta.
>> >>>
>> >>> Cuando intento crear un indice sobre esa columna sql 2005 me dice:
>> >>>
>> >>> Mens. 2709, Nivel 16, Estado 1, Línea 1
>> >>> La columna 'F_CAL_INI' de tabla 'VALORES' no se puede usar en un
>> >>> índice
>> >>> o en
>> >>> estadísticas, o como una clave de partición, porque tiene acceso a
>> >>> datos
>> >>> del
>> >>> usuario o sistema.
>> >>>
>> >>> Alguien puede decirme a que es debido y como solucionarlo???
>> >>>
>> >>> Gracias
>> >>>
>> >>>
>> >>>
>> >
>> >
>>
>>
>>

Estas tres consultas me dan 1, lo que es lo mismo true, osea que la funcion
es determinista y precisa y se ha creado con la opcion SET ANSI_NULLS ON
activada.

SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'), 'IsDeterministic')
SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'), 'IsPrecise')
SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'), 'IsAnsiNullsOn')

Estoy mirando otra cosa. Y es que en los BOL, sobre las columnas calculadas
dice literalmente:

"Las columnas calculadas se calculan a partir de una expresión que puede
utilizar otras columnas de la misma tabla."

Dice de la misma tabla. Yo estoy intentando crear una columna calculada con
una funcion que tiene una select de otras dos tablas. Puede ser por eso????

¿¿¿¿Alguien ha hecho alguna funcion de columna calculada persistente que
acceda a datos de otra tabla????

"Alejandro Mesa" escribió en el
mensaje news:

GenioMaestro,

Chequea el tema "Creating Indexes on Computed Columns" en los BOL. Puede
ser
que como calculas el valor a partir de multiples filas, esto hace que la
funcion sea no determinista. Usa la funcion "objectproperty" para
comprobar
si la funcion es determinista y en caso de ser determinista verifica si es
imprescisa, creo que en ese caso puedes usar la opcion "persisted" cuando
creas la columna y sql server dejara crear un indice.

Creating Indexes on Computed Columns
http://msdn2.microsoft.com/en-us/li...89292.aspx

> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND COTIZACIONES.FECHA
> >> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND .CALCULOS.FECHA_CAL IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC

A proposito, yo no usaria "left join" para comprobar existencia. Usaria el
operador "exists" a cambio. De todas maneras prueba ambas versiones a ver
cual te da mejor resultado. Tambien ve si tener un indice en
[COTIZACIONES]
por [COD_VALOR] ayuda a mejorar el plan de ejecucion.

SELECT TOP 1
c.FECHA
FROM
DBO.COTIZACIONES as a
WHERE
c.COD_VALOR = @entra_valor
and not exists (
select *
from DBO.CALCULOS as b
where
b.COD_VALOR = a.COD_VALOR
and b.FECHA_CAL = a.FECHA
)
ORDER BY
c.FECHA ASC
go


AMB

"GenioMaestro" wrote:

Y además, esta consulta tampoco me la paraleliza, tarda dos o tres
minutos
en darme la select con la columna calculada, porque la está calculando al
vuelo, cada vez que la pido, y con el micro al 50%, claro.

Hay alguna manera de forzar al sql server 2005 para que paralelize una
consulta????



"GenioMaestro" escribió en el mensaje
news:
> Va la funcion:
>
> ALTER FUNCTION [dbo].[FECHA_CAL_INI] (@entra_valor as INT)
> RETURNS DATETIME
> WITH SCHEMABINDING
> BEGIN
>
> RETURN (
> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND COTIZACIONES.FECHA
> >> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND .CALCULOS.FECHA_CAL IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC
> )
> END
>
> Gracias por el interes, Alejandro.
>
>
>
> "Alejandro Mesa" escribió en
> el
> mensaje news:
>> GenioMaestro,
>>
>> Pudieras mostrarnos la funcion?
>>
>>
>> AMB
>>
>> "GenioMaestro" wrote:
>>
>>> Hola:
>>>
>>> He creado una columna calculada en base a una funcion de usuario que
>>> funciona bien, pero es muy lenta.
>>>
>>> Cuando intento crear un indice sobre esa columna sql 2005 me dice:
>>>
>>> Mens. 2709, Nivel 16, Estado 1, Línea 1
>>> La columna 'F_CAL_INI' de tabla 'VALORES' no se puede usar en un
>>> índice
>>> o en
>>> estadísticas, o como una clave de partición, porque tiene acceso a
>>> datos
>>> del
>>> usuario o sistema.
>>>
>>> Alguien puede decirme a que es debido y como solucionarlo???
>>>
>>> Gracias
>>>
>>>
>>>
>
>

Además he visto en el enlace que me pasaste que para que una funcion se
determinista dice literalmente:

Has no system data access or user data access. (No tiene acceso a los datos
del sistema o de usuario.)

Es decir, si accede a datos de usuario ya no es determinista, aunque la
primera de las tres select diga que si.

Es un poco absurdo, no???


"GenioMaestro" escribió en el mensaje
news:

Estas tres consultas me dan 1, lo que es lo mismo true, osea que la
funcion es determinista y precisa y se ha creado con la opcion SET
ANSI_NULLS ON activada.

SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'), 'IsDeterministic')
SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'), 'IsPrecise')
SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'), 'IsAnsiNullsOn')

Estoy mirando otra cosa. Y es que en los BOL, sobre las columnas
calculadas dice literalmente:

"Las columnas calculadas se calculan a partir de una expresión que puede
utilizar otras columnas de la misma tabla."

Dice de la misma tabla. Yo estoy intentando crear una columna calculada
con una funcion que tiene una select de otras dos tablas. Puede ser por
eso????

¿¿¿¿Alguien ha hecho alguna funcion de columna calculada persistente que
acceda a datos de otra tabla????

"Alejandro Mesa" escribió en el
mensaje news:

GenioMaestro,

Chequea el tema "Creating Indexes on Computed Columns" en los BOL. Puede
ser
que como calculas el valor a partir de multiples filas, esto hace que la
funcion sea no determinista. Usa la funcion "objectproperty" para
comprobar
si la funcion es determinista y en caso de ser determinista verifica si
es
imprescisa, creo que en ese caso puedes usar la opcion "persisted" cuando
creas la columna y sql server dejara crear un indice.

Creating Indexes on Computed Columns
http://msdn2.microsoft.com/en-us/li...89292.aspx

> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND COTIZACIONES.FECHA
> >>> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND .CALCULOS.FECHA_CAL IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC

A proposito, yo no usaria "left join" para comprobar existencia. Usaria
el
operador "exists" a cambio. De todas maneras prueba ambas versiones a ver
cual te da mejor resultado. Tambien ve si tener un indice en
[COTIZACIONES]
por [COD_VALOR] ayuda a mejorar el plan de ejecucion.

SELECT TOP 1
c.FECHA
FROM
DBO.COTIZACIONES as a
WHERE
c.COD_VALOR = @entra_valor
and not exists (
select *
from DBO.CALCULOS as b
where
b.COD_VALOR = a.COD_VALOR
and b.FECHA_CAL = a.FECHA
)
ORDER BY
c.FECHA ASC
go


AMB

"GenioMaestro" wrote:

Y además, esta consulta tampoco me la paraleliza, tarda dos o tres
minutos
en darme la select con la columna calculada, porque la está calculando
al
vuelo, cada vez que la pido, y con el micro al 50%, claro.

Hay alguna manera de forzar al sql server 2005 para que paralelize una
consulta????



"GenioMaestro" escribió en el mensaje
news:
> Va la funcion:
>
> ALTER FUNCTION [dbo].[FECHA_CAL_INI] (@entra_valor as INT)
> RETURNS DATETIME
> WITH SCHEMABINDING
> BEGIN
>
> RETURN (
> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND COTIZACIONES.FECHA
> >>> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND .CALCULOS.FECHA_CAL IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC
> )
> END
>
> Gracias por el interes, Alejandro.
>
>
>
> "Alejandro Mesa" escribió en
> el
> mensaje news:
>> GenioMaestro,
>>
>> Pudieras mostrarnos la funcion?
>>
>>
>> AMB
>>
>> "GenioMaestro" wrote:
>>
>>> Hola:
>>>
>>> He creado una columna calculada en base a una funcion de usuario que
>>> funciona bien, pero es muy lenta.
>>>
>>> Cuando intento crear un indice sobre esa columna sql 2005 me dice:
>>>
>>> Mens. 2709, Nivel 16, Estado 1, Línea 1
>>> La columna 'F_CAL_INI' de tabla 'VALORES' no se puede usar en un
>>> índice
>>> o en
>>> estadísticas, o como una clave de partición, porque tiene acceso a
>>> datos
>>> del
>>> usuario o sistema.
>>>
>>> Alguien puede decirme a que es debido y como solucionarlo???
>>>
>>> Gracias
>>>
>>>
>>>
>
>

GenioMaestro, porque mejor no haces una vista ? Yo creo que es mejor usar
una funcion en una columna calculada cuando sea una simple que no maneje
datos ya que el overhead puede ser muy alto.



"GenioMaestro" wrote in message
news:

Además he visto en el enlace que me pasaste que para que una funcion se
determinista dice literalmente:

Has no system data access or user data access. (No tiene acceso a los
datos del sistema o de usuario.)

Es decir, si accede a datos de usuario ya no es determinista, aunque la
primera de las tres select diga que si.

Es un poco absurdo, no???


"GenioMaestro" escribió en el mensaje
news:

Estas tres consultas me dan 1, lo que es lo mismo true, osea que la
funcion es determinista y precisa y se ha creado con la opcion SET
ANSI_NULLS ON activada.

SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'),
'IsDeterministic')
SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'), 'IsPrecise')
SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'), 'IsAnsiNullsOn')

Estoy mirando otra cosa. Y es que en los BOL, sobre las columnas
calculadas dice literalmente:

"Las columnas calculadas se calculan a partir de una expresión que puede
utilizar otras columnas de la misma tabla."

Dice de la misma tabla. Yo estoy intentando crear una columna calculada
con una funcion que tiene una select de otras dos tablas. Puede ser por
eso????

¿¿¿¿Alguien ha hecho alguna funcion de columna calculada persistente que
acceda a datos de otra tabla????

"Alejandro Mesa" escribió en el
mensaje news:

GenioMaestro,

Chequea el tema "Creating Indexes on Computed Columns" en los BOL. Puede
ser
que como calculas el valor a partir de multiples filas, esto hace que la
funcion sea no determinista. Usa la funcion "objectproperty" para
comprobar
si la funcion es determinista y en caso de ser determinista verifica si
es
imprescisa, creo que en ese caso puedes usar la opcion "persisted"
cuando
creas la columna y sql server dejara crear un indice.

Creating Indexes on Computed Columns
http://msdn2.microsoft.com/en-us/li...89292.aspx

> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND
> COTIZACIONES.FECHA >>>> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND .CALCULOS.FECHA_CAL
> IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC

A proposito, yo no usaria "left join" para comprobar existencia. Usaria
el
operador "exists" a cambio. De todas maneras prueba ambas versiones a
ver
cual te da mejor resultado. Tambien ve si tener un indice en
[COTIZACIONES]
por [COD_VALOR] ayuda a mejorar el plan de ejecucion.

SELECT TOP 1
c.FECHA
FROM
DBO.COTIZACIONES as a
WHERE
c.COD_VALOR = @entra_valor
and not exists (
select *
from DBO.CALCULOS as b
where
b.COD_VALOR = a.COD_VALOR
and b.FECHA_CAL = a.FECHA
)
ORDER BY
c.FECHA ASC
go


AMB

"GenioMaestro" wrote:

Y además, esta consulta tampoco me la paraleliza, tarda dos o tres
minutos
en darme la select con la columna calculada, porque la está calculando
al
vuelo, cada vez que la pido, y con el micro al 50%, claro.

Hay alguna manera de forzar al sql server 2005 para que paralelize una
consulta????



"GenioMaestro" escribió en el mensaje
news:
> Va la funcion:
>
> ALTER FUNCTION [dbo].[FECHA_CAL_INI] (@entra_valor as INT)
> RETURNS DATETIME
> WITH SCHEMABINDING
> BEGIN
>
> RETURN (
> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND
> COTIZACIONES.FECHA >>>> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND .CALCULOS.FECHA_CAL
> IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC
> )
> END
>
> Gracias por el interes, Alejandro.
>
>
>
> "Alejandro Mesa" escribió
> en el
> mensaje news:
>> GenioMaestro,
>>
>> Pudieras mostrarnos la funcion?
>>
>>
>> AMB
>>
>> "GenioMaestro" wrote:
>>
>>> Hola:
>>>
>>> He creado una columna calculada en base a una funcion de usuario
>>> que
>>> funciona bien, pero es muy lenta.
>>>
>>> Cuando intento crear un indice sobre esa columna sql 2005 me dice:
>>>
>>> Mens. 2709, Nivel 16, Estado 1, Línea 1
>>> La columna 'F_CAL_INI' de tabla 'VALORES' no se puede usar en un
>>> índice
>>> o en
>>> estadísticas, o como una clave de partición, porque tiene acceso a
>>> datos
>>> del
>>> usuario o sistema.
>>>
>>> Alguien puede decirme a que es debido y como solucionarlo???
>>>
>>> Gracias
>>>
>>>
>>>
>
>