Otra consulta

Maxi,

Te invito a que leas el articulo ligado al link posteado. En el encontraras
una muy buena explicacion sobre este tema, incluyendo tablas de comparacion
entre los diferentes metodos.


AMB

"Maxi" wrote:

Hola, porque dices q no es optima, mira yo lo uso mucho y es muy optima!! en
que te basas o que experiencias has tenido con esto para indicar q no es
optima?


Maxi - Buenos Aires - Argentina
Desarrollador 3 Estrellas

Msn_messager:
mail: Maxi.da[arroba]gmail.com

"Alejandro Mesa" escribió en el
mensaje news:
> Nicolas Ibarra Salazar,
>
> Como indico Maxi, pudieras pasar los valores en un documento xml como
> parametro de entrada a un procedimiento almacenado. Esta opcion no es la
> mas
> optima, al menos en sql server 2000. Existen otras formas de simular
> arreglos
> en t-sql. Aca te paso un link donde podras leer sobre las multiples
> opciones
> que existen para hacer esto en sql server.
>
> Arrays and Lists in SQL Server
> http://www.sommarskog.se/arrays-in-sql.html
>
>
> AMB
>
> "Nicolas Ibarra Salazar" wrote:
>
>> En una SELECT, cómo hago para pasarle más de un valor proveniente de un
>> combo que permita multiples selecciones:
>>
>> Ej:
>> <select name="rubro" size="10" multiple>
>> <option value="1">Accesorios</option>
>> <option value="2">Servicios</option>
>> <option value="3">Depósito</option>
>>
>> </select>
>>
>> El tema es, en la query, cual es el operador para pasarle estos valores
>> que
>> si no me equivoco van separados por comas?
>>
>> SELECT * FROM rubros WHERE rubro "=" "IN" "ON" "IS" ??????
>>
>> Probé con = y no trae ningun resultado cuando se elige mas de 1 opcion en
>> el
>> combo.
>>
>> Alguna idea?
>>
>> Saludos.
>> Nicolas
>>
>>
>>

Ale, lo lei el articulo pero a ver: las otras alternativas no me parecen
muy buenas que digamos :S, te comento que estoy usando XML con grandes datos
y funciona muy pero muy rapído de verdad. La ventaja a xml que le veo son
muchas

1) Usas un formato standard y aislas mucho el SP's
2) La performance como te indique no se ve casi nada afectada, yo como te
dije lo uso mucho y en soft con muchas transacciones en un sistemas ERP
3) Es muy simple de usar
4) Es mucho mas seguro que usar SQL dinamico ;-)
5) Dejas todo bien armadito para sql2005 sin mayores cambios

De todas maneras agradesco tu articulo, pero como te indique yo uso XMl en
sql desde hace un rato largo en sistemas criticos y la verdad que hasta el
momento me parece la mejor solucion a pasar datos Array a un Sp's



Maxi - Buenos Aires - Argentina
Desarrollador 3 Estrellas

Msn_messager:
mail: Maxi.da[arroba]gmail.com

"Alejandro Mesa" escribió en el
mensaje news:

Maxi,

Te invito a que leas el articulo ligado al link posteado. En el
encontraras
una muy buena explicacion sobre este tema, incluyendo tablas de
comparacion
entre los diferentes metodos.


AMB

"Maxi" wrote:

Hola, porque dices q no es optima, mira yo lo uso mucho y es muy optima!!
en
que te basas o que experiencias has tenido con esto para indicar q no es
optima?


Maxi - Buenos Aires - Argentina
Desarrollador 3 Estrellas

Msn_messager:
mail: Maxi.da[arroba]gmail.com

"Alejandro Mesa" escribió en el
mensaje news:
> Nicolas Ibarra Salazar,
>
> Como indico Maxi, pudieras pasar los valores en un documento xml como
> parametro de entrada a un procedimiento almacenado. Esta opcion no es
> la
> mas
> optima, al menos en sql server 2000. Existen otras formas de simular
> arreglos
> en t-sql. Aca te paso un link donde podras leer sobre las multiples
> opciones
> que existen para hacer esto en sql server.
>
> Arrays and Lists in SQL Server
> http://www.sommarskog.se/arrays-in-sql.html
>
>
> AMB
>
> "Nicolas Ibarra Salazar" wrote:
>
>> En una SELECT, cómo hago para pasarle más de un valor proveniente de
>> un
>> combo que permita multiples selecciones:
>>
>> Ej:
>> <select name="rubro" size="10" multiple>
>> <option value="1">Accesorios</option>
>> <option value="2">Servicios</option>
>> <option value="3">Depósito</option>
>>
>> </select>
>>
>> El tema es, en la query, cual es el operador para pasarle estos
>> valores
>> que
>> si no me equivoco van separados por comas?
>>
>> SELECT * FROM rubros WHERE rubro "=" "IN" "ON" "IS" ??????
>>
>> Probé con = y no trae ningun resultado cuando se elige mas de 1 opcion
>> en
>> el
>> combo.
>>
>> Alguna idea?
>>
>> Saludos.
>> Nicolas
>>
>>
>>

1) Usas un formato standard y aislas mucho el SP's

Lo mismo si usas las otras opciones y pones el codigo en una funcion de
usuario que te devuelva una tabla con los valores pasados en la cadena.

2) La performance como te indique no se ve casi nada afectada, yo como te
dije lo uso mucho y en soft con muchas transacciones en un sistemas ERP

Hicistes alguna comparacion entre xml y los otros metodos?

3) Es muy simple de usar

Lo mismo digo de los otros.

4) Es mucho mas seguro que usar SQL dinamico ;-)

Nadie ha hablado de usar sql dinamico.

5) Dejas todo bien armadito para sql2005 sin mayores cambios

Lo mismo si usas una funcion definida de usuario.


Maxi, no tengo nada en contra de usar xml, por el contrario, cuando quieres
pasar multiple informacion por fila, o representar jerarquias, xml es la via
correcta. Para simular un arreglo uni dimensional en t-sql, usar xml es una
opcion posible pero no optima. La cantidad de informacion enviada atraves de
la red es mayor, debes usar al menos dos sps que son sp_xml_preparedocument,
sp_xml_removedocument y la funcion OPENXML.

Aqui posteo un ejemplo, el cual corri un x numero de veces y como promedio
el metodo uno obtuvo un tiempo mas bajo. Esto no dice nada, se deben hacer
pruebas antes de tomar una decision y si obtener un mejor tiempo, en el order
de las milesimas de segundo o segundos, no es importante para tu sistema
entonces escoje la que mejor te convenga pero si ganar un milisegundo es
importante para tu aplicacion entonces usar xml para simular un arreglo
unidimensional en t-sql no es la opcion optima.

use northwind
go

select
identity(int, 1, 1) as number
into
dbo.number
from
sysobjects as a
cross join
sysobjects as b
go

alter table dbo.number
add constraint pk_number primary key clustered (number)
go

create function dbo.inline_split_me (
@param varchar(7998)
)
returns table
as
RETURN(
select
substring(',' + @param + ',', Number + 1,
charindex(',', ',' + @param + ',', Number + 1) - Number
- 1
) as Value
from
dbo.Number
where
Number <= len(',' + @param + ',') - 1
AND substring(',' + @param + ',', Number, 1) = ','
)
go

declare @sd datetime
declare @ed datetime
declare @s varchar(7998)
declare @doc varchar(7998)
declare @idoc int

set @s =
'10250,10893,10937,10946,10392,10260,10378,10879,11008,11045,10715,11031,11059'
set @doc = '
<ROOT>
<Order OrderID="10250"/>
<Order OrderID="10893"/>
<Order OrderID="10937"/>
<Order OrderID="10946"/>
<Order OrderID="10392"/>
<Order OrderID="10260"/>
<Order OrderID="10378"/>
<Order OrderID="10879"/>
<Order OrderID="11008"/>
<Order OrderID="11045"/>
<Order OrderID="10715"/>
<Order OrderID="11031"/>
<Order OrderID="11059"/>
</ROOT>'

dbcc freeproccache
dbcc dropcleanbuffers

set @sd = getdate()

select
oh.orderid,
oh.customerid,
oh.orderdate
from
dbo.orders as oh
inner join
dbo.inline_split_me(@s) as a
on oh.orderid = a.value

set @ed = getdate()

select datediff(millisecond, @sd, @ed)

dbcc freeproccache
dbcc dropcleanbuffers

set @sd = getdate()

exec sp_xml_preparedocument @idoc OUTPUT, @doc

select
oh.orderid,
oh.customerid,
oh.orderdate
from
dbo.orders as oh
inner join
openxml(@idoc, '/ROOT/Order', 1)
with (OrderID int) as a
on oh.orderid = a.orderid

exec sp_xml_removedocument @idoc

set @ed = getdate()

select datediff(millisecond, @sd, @ed)
go

drop function inline_split_me
go

drop table dbo.number
go


Saludos,


AMB


"Maxi" wrote:

Ale, lo lei el articulo pero a ver: las otras alternativas no me parecen
muy buenas que digamos :S, te comento que estoy usando XML con grandes datos
y funciona muy pero muy rapído de verdad. La ventaja a xml que le veo son
muchas

1) Usas un formato standard y aislas mucho el SP's
2) La performance como te indique no se ve casi nada afectada, yo como te
dije lo uso mucho y en soft con muchas transacciones en un sistemas ERP
3) Es muy simple de usar
4) Es mucho mas seguro que usar SQL dinamico ;-)
5) Dejas todo bien armadito para sql2005 sin mayores cambios

De todas maneras agradesco tu articulo, pero como te indique yo uso XMl en
sql desde hace un rato largo en sistemas criticos y la verdad que hasta el
momento me parece la mejor solucion a pasar datos Array a un Sp's



Maxi - Buenos Aires - Argentina
Desarrollador 3 Estrellas

Msn_messager:
mail: Maxi.da[arroba]gmail.com

"Alejandro Mesa" escribió en el
mensaje news:
> Maxi,
>
> Te invito a que leas el articulo ligado al link posteado. En el
> encontraras
> una muy buena explicacion sobre este tema, incluyendo tablas de
> comparacion
> entre los diferentes metodos.
>
>
> AMB
>
> "Maxi" wrote:
>
>> Hola, porque dices q no es optima, mira yo lo uso mucho y es muy optima!!
>> en
>> que te basas o que experiencias has tenido con esto para indicar q no es
>> optima?
>>
>>
>> Maxi - Buenos Aires - Argentina
>> Desarrollador 3 Estrellas
>>
>> Msn_messager:
>> mail: Maxi.da[arroba]gmail.com
>>
>> "Alejandro Mesa" escribió en el
>> mensaje news:
>> > Nicolas Ibarra Salazar,
>> >
>> > Como indico Maxi, pudieras pasar los valores en un documento xml como
>> > parametro de entrada a un procedimiento almacenado. Esta opcion no es
>> > la
>> > mas
>> > optima, al menos en sql server 2000. Existen otras formas de simular
>> > arreglos
>> > en t-sql. Aca te paso un link donde podras leer sobre las multiples
>> > opciones
>> > que existen para hacer esto en sql server.
>> >
>> > Arrays and Lists in SQL Server
>> > http://www.sommarskog.se/arrays-in-sql.html
>> >
>> >
>> > AMB
>> >
>> > "Nicolas Ibarra Salazar" wrote:
>> >
>> >> En una SELECT, cómo hago para pasarle más de un valor proveniente de
>> >> un
>> >> combo que permita multiples selecciones:
>> >>
>> >> Ej:
>> >> <select name="rubro" size="10" multiple>
>> >> <option value="1">Accesorios</option>
>> >> <option value="2">Servicios</option>
>> >> <option value="3">Depósito</option>
>> >>
>> >> </select>
>> >>
>> >> El tema es, en la query, cual es el operador para pasarle estos
>> >> valores
>> >> que
>> >> si no me equivoco van separados por comas?
>> >>
>> >> SELECT * FROM rubros WHERE rubro "=" "IN" "ON" "IS" ??????
>> >>
>> >> Probé con = y no trae ningun resultado cuando se elige mas de 1 opcion
>> >> en
>> >> el
>> >> combo.
>> >>
>> >> Alguna idea?
>> >>
>> >> Saludos.
>> >> Nicolas
>> >>
>> >>
>> >>
>>
>>
>>

Hola Ale, sigamos que el tema es interesante :-)

Lo mismo si usas las otras opciones y pones el codigo en una funcion de
usuario que te devuelva una tabla con los valores pasados en la cadena.

mmm. no es tan asi, una cosa es una cadena XML que cualquier soft puede
interpretar ya que es un Standard y la otra es que vos te armes un modelo y
luego le debas explicar a todos como funciona, no es lo mismo. El xml desde
el cliente se genera con una simple instruccion y es un formato standard el
cual no hay que inventar nada, si vos armas un formato para que de alguna
manera te pasen los datos, no es lo mismo. En tu mismo ejemplo veamos como
hacemos una cosa: Vos ahi solo pasaste un campo y la cosa es simple parece,
ahora veamos que sucede si debo pasar la linea de una OC (Orden de compra
por ej) es mas complejo porque tenes mas de un campo y ni hablar si el dia
de mañana cambia la entrada, usando xml es totalmente transparente.

3) Es muy simple de usar

Lo mismo digo de los otros.

Con un solo campo si, ahora tenes 20 campos que pasar, es tan simple?

Te vuelvo a repetir lo mismo, con un solo campo lo veo entre comillas bien,
por un lado no me es grato q vos definas un formato y no sea nada Standard
(para que inventar la rueda cuando otro ya la invento ;-), y ademas cuando
tenes una matriz compleja no veo facil solucion si no lo haces con XML, hay
otras soluciones usando tablas temporales o sql-dinamico pero...

Yo cuando me referia a q lo tenia en produccion me referia a pasar
documentos como por ej OC, Facturas, etc. Y esto antes lo tenia de la otra
manera, cuando empece a probar XML la diferencia fue muy notoria, no solo en
perfomance, sino que tambien en facilidad, interpretacion, aislacion con
metodo StandarD (al cliente solo le digo, mandame un XML y ya, bue fueron
muchas las ventajas, ni hablar del manejo de transacciones y control de
errores.

Un abrazo


Salu2
Maxi


"Alejandro Mesa" escribió en el
mensaje news:

1) Usas un formato standard y aislas mucho el SP's

Lo mismo si usas las otras opciones y pones el codigo en una funcion de
usuario que te devuelva una tabla con los valores pasados en la cadena.

2) La performance como te indique no se ve casi nada afectada, yo como te
dije lo uso mucho y en soft con muchas transacciones en un sistemas ERP

Hicistes alguna comparacion entre xml y los otros metodos?

3) Es muy simple de usar

Lo mismo digo de los otros.

4) Es mucho mas seguro que usar SQL dinamico ;-)

Nadie ha hablado de usar sql dinamico.

5) Dejas todo bien armadito para sql2005 sin mayores cambios

Lo mismo si usas una funcion definida de usuario.


Maxi, no tengo nada en contra de usar xml, por el contrario, cuando
quieres
pasar multiple informacion por fila, o representar jerarquias, xml es la
via
correcta. Para simular un arreglo uni dimensional en t-sql, usar xml es
una
opcion posible pero no optima. La cantidad de informacion enviada atraves
de
la red es mayor, debes usar al menos dos sps que son
sp_xml_preparedocument,
sp_xml_removedocument y la funcion OPENXML.

Aqui posteo un ejemplo, el cual corri un x numero de veces y como promedio
el metodo uno obtuvo un tiempo mas bajo. Esto no dice nada, se deben hacer
pruebas antes de tomar una decision y si obtener un mejor tiempo, en el
order
de las milesimas de segundo o segundos, no es importante para tu sistema
entonces escoje la que mejor te convenga pero si ganar un milisegundo es
importante para tu aplicacion entonces usar xml para simular un arreglo
unidimensional en t-sql no es la opcion optima.

use northwind
go

select
identity(int, 1, 1) as number
into
dbo.number
from
sysobjects as a
cross join
sysobjects as b
go

alter table dbo.number
add constraint pk_number primary key clustered (number)
go

create function dbo.inline_split_me (
@param varchar(7998)
)
returns table
as
RETURN(
select
substring(',' + @param + ',', Number + 1,
charindex(',', ',' + @param + ',', Number + 1) - Number
- 1
) as Value
from
dbo.Number
where
Number <= len(',' + @param + ',') - 1
AND substring(',' + @param + ',', Number, 1) = ','
)
go

declare @sd datetime
declare @ed datetime
declare @s varchar(7998)
declare @doc varchar(7998)
declare @idoc int

set @s > '10250,10893,10937,10946,10392,10260,10378,10879,11008,11045,10715,11031,11059'
set @doc = '
<ROOT>
<Order OrderID="10250"/>
<Order OrderID="10893"/>
<Order OrderID="10937"/>
<Order OrderID="10946"/>
<Order OrderID="10392"/>
<Order OrderID="10260"/>
<Order OrderID="10378"/>
<Order OrderID="10879"/>
<Order OrderID="11008"/>
<Order OrderID="11045"/>
<Order OrderID="10715"/>
<Order OrderID="11031"/>
<Order OrderID="11059"/>
</ROOT>'

dbcc freeproccache
dbcc dropcleanbuffers

set @sd = getdate()

select
oh.orderid,
oh.customerid,
oh.orderdate
from
dbo.orders as oh
inner join
dbo.inline_split_me(@s) as a
on oh.orderid = a.value

set @ed = getdate()

select datediff(millisecond, @sd, @ed)

dbcc freeproccache
dbcc dropcleanbuffers

set @sd = getdate()

exec sp_xml_preparedocument @idoc OUTPUT, @doc

select
oh.orderid,
oh.customerid,
oh.orderdate
from
dbo.orders as oh
inner join
openxml(@idoc, '/ROOT/Order', 1)
with (OrderID int) as a
on oh.orderid = a.orderid

exec sp_xml_removedocument @idoc

set @ed = getdate()

select datediff(millisecond, @sd, @ed)
go

drop function inline_split_me
go

drop table dbo.number
go


Saludos,


AMB


"Maxi" wrote:

Ale, lo lei el articulo pero a ver: las otras alternativas no me parecen
muy buenas que digamos :S, te comento que estoy usando XML con grandes
datos
y funciona muy pero muy rapído de verdad. La ventaja a xml que le veo son
muchas

1) Usas un formato standard y aislas mucho el SP's
2) La performance como te indique no se ve casi nada afectada, yo como te
dije lo uso mucho y en soft con muchas transacciones en un sistemas ERP
3) Es muy simple de usar
4) Es mucho mas seguro que usar SQL dinamico ;-)
5) Dejas todo bien armadito para sql2005 sin mayores cambios

De todas maneras agradesco tu articulo, pero como te indique yo uso XMl
en
sql desde hace un rato largo en sistemas criticos y la verdad que hasta
el
momento me parece la mejor solucion a pasar datos Array a un Sp's



Maxi - Buenos Aires - Argentina
Desarrollador 3 Estrellas

Msn_messager:
mail: Maxi.da[arroba]gmail.com

"Alejandro Mesa" escribió en el
mensaje news:
> Maxi,
>
> Te invito a que leas el articulo ligado al link posteado. En el
> encontraras
> una muy buena explicacion sobre este tema, incluyendo tablas de
> comparacion
> entre los diferentes metodos.
>
>
> AMB
>
> "Maxi" wrote:
>
>> Hola, porque dices q no es optima, mira yo lo uso mucho y es muy
>> optima!!
>> en
>> que te basas o que experiencias has tenido con esto para indicar q no
>> es
>> optima?
>>
>>
>> Maxi - Buenos Aires - Argentina
>> Desarrollador 3 Estrellas
>>
>> Msn_messager:
>> mail: Maxi.da[arroba]gmail.com
>>
>> "Alejandro Mesa" escribió en
>> el
>> mensaje news:
>> > Nicolas Ibarra Salazar,
>> >
>> > Como indico Maxi, pudieras pasar los valores en un documento xml
>> > como
>> > parametro de entrada a un procedimiento almacenado. Esta opcion no
>> > es
>> > la
>> > mas
>> > optima, al menos en sql server 2000. Existen otras formas de simular
>> > arreglos
>> > en t-sql. Aca te paso un link donde podras leer sobre las multiples
>> > opciones
>> > que existen para hacer esto en sql server.
>> >
>> > Arrays and Lists in SQL Server
>> > http://www.sommarskog.se/arrays-in-sql.html
>> >
>> >
>> > AMB
>> >
>> > "Nicolas Ibarra Salazar" wrote:
>> >
>> >> En una SELECT, cómo hago para pasarle más de un valor proveniente
>> >> de
>> >> un
>> >> combo que permita multiples selecciones:
>> >>
>> >> Ej:
>> >> <select name="rubro" size="10" multiple>
>> >> <option value="1">Accesorios</option>
>> >> <option value="2">Servicios</option>
>> >> <option value="3">Depósito</option>
>> >>
>> >> </select>
>> >>
>> >> El tema es, en la query, cual es el operador para pasarle estos
>> >> valores
>> >> que
>> >> si no me equivoco van separados por comas?
>> >>
>> >> SELECT * FROM rubros WHERE rubro "=" "IN" "ON" "IS"
>> >> ??????
>> >>
>> >> Probé con = y no trae ningun resultado cuando se elige mas de 1
>> >> opcion
>> >> en
>> >> el
>> >> combo.
>> >>
>> >> Alguna idea?
>> >>
>> >> Saludos.
>> >> Nicolas
>> >>
>> >>
>> >>
>>
>>
>>

Maxi,

Desde mi primer post, me estoy refiriendo a simular arreglos uni
dimensionales (una sola dimension, una lista de valores) en t-sql. La
pregunta original fue como pasar una multi-seleccion a sql server. En cuanto
a todo lo demas que tiene que ver con xml estoy de acuerdo y no lo he puesto
en duda.

(para que inventar la rueda cuando otro ya la invento ;-), y ademas cuando

Si asi hubiesen pensado los que crearon XML, entonces no lo hubieran hecho,
pues XML al igual que HTML, fue tomado del estandard SGML.


AMB

"Maxi" wrote:

Hola Ale, sigamos que el tema es interesante :-)

> Lo mismo si usas las otras opciones y pones el codigo en una funcion de
> usuario que te devuelva una tabla con los valores pasados en la cadena.

mmm. no es tan asi, una cosa es una cadena XML que cualquier soft puede
interpretar ya que es un Standard y la otra es que vos te armes un modelo y
luego le debas explicar a todos como funciona, no es lo mismo. El xml desde
el cliente se genera con una simple instruccion y es un formato standard el
cual no hay que inventar nada, si vos armas un formato para que de alguna
manera te pasen los datos, no es lo mismo. En tu mismo ejemplo veamos como
hacemos una cosa: Vos ahi solo pasaste un campo y la cosa es simple parece,
ahora veamos que sucede si debo pasar la linea de una OC (Orden de compra
por ej) es mas complejo porque tenes mas de un campo y ni hablar si el dia
de mañana cambia la entrada, usando xml es totalmente transparente.

>> 3) Es muy simple de usar
>
> Lo mismo digo de los otros.

Con un solo campo si, ahora tenes 20 campos que pasar, es tan simple?

Te vuelvo a repetir lo mismo, con un solo campo lo veo entre comillas bien,
por un lado no me es grato q vos definas un formato y no sea nada Standard
(para que inventar la rueda cuando otro ya la invento ;-), y ademas cuando
tenes una matriz compleja no veo facil solucion si no lo haces con XML, hay
otras soluciones usando tablas temporales o sql-dinamico pero...

Yo cuando me referia a q lo tenia en produccion me referia a pasar
documentos como por ej OC, Facturas, etc. Y esto antes lo tenia de la otra
manera, cuando empece a probar XML la diferencia fue muy notoria, no solo en
perfomance, sino que tambien en facilidad, interpretacion, aislacion con
metodo StandarD (al cliente solo le digo, mandame un XML y ya, bue fueron
muchas las ventajas, ni hablar del manejo de transacciones y control de
errores.

Un abrazo


Salu2
Maxi


"Alejandro Mesa" escribió en el
mensaje news:
>> 1) Usas un formato standard y aislas mucho el SP's
>
> Lo mismo si usas las otras opciones y pones el codigo en una funcion de
> usuario que te devuelva una tabla con los valores pasados en la cadena.
>
>> 2) La performance como te indique no se ve casi nada afectada, yo como te
>> dije lo uso mucho y en soft con muchas transacciones en un sistemas ERP
>
> Hicistes alguna comparacion entre xml y los otros metodos?
>
>> 3) Es muy simple de usar
>
> Lo mismo digo de los otros.
>
>> 4) Es mucho mas seguro que usar SQL dinamico ;-)
>
> Nadie ha hablado de usar sql dinamico.
>
>> 5) Dejas todo bien armadito para sql2005 sin mayores cambios
>
> Lo mismo si usas una funcion definida de usuario.
>
>
> Maxi, no tengo nada en contra de usar xml, por el contrario, cuando
> quieres
> pasar multiple informacion por fila, o representar jerarquias, xml es la
> via
> correcta. Para simular un arreglo uni dimensional en t-sql, usar xml es
> una
> opcion posible pero no optima. La cantidad de informacion enviada atraves
> de
> la red es mayor, debes usar al menos dos sps que son
> sp_xml_preparedocument,
> sp_xml_removedocument y la funcion OPENXML.
>
> Aqui posteo un ejemplo, el cual corri un x numero de veces y como promedio
> el metodo uno obtuvo un tiempo mas bajo. Esto no dice nada, se deben hacer
> pruebas antes de tomar una decision y si obtener un mejor tiempo, en el
> order
> de las milesimas de segundo o segundos, no es importante para tu sistema
> entonces escoje la que mejor te convenga pero si ganar un milisegundo es
> importante para tu aplicacion entonces usar xml para simular un arreglo
> unidimensional en t-sql no es la opcion optima.
>
> use northwind
> go
>
> select
> identity(int, 1, 1) as number
> into
> dbo.number
> from
> sysobjects as a
> cross join
> sysobjects as b
> go
>
> alter table dbo.number
> add constraint pk_number primary key clustered (number)
> go
>
> create function dbo.inline_split_me (
> @param varchar(7998)
> )
> returns table
> as
> RETURN(
> select
> substring(',' + @param + ',', Number + 1,
> charindex(',', ',' + @param + ',', Number + 1) - Number
> - 1
> ) as Value
> from
> dbo.Number
> where
> Number <= len(',' + @param + ',') - 1
> AND substring(',' + @param + ',', Number, 1) = ','
> )
> go
>
> declare @sd datetime
> declare @ed datetime
> declare @s varchar(7998)
> declare @doc varchar(7998)
> declare @idoc int
>
> set @s > > '10250,10893,10937,10946,10392,10260,10378,10879,11008,11045,10715,11031,11059'
> set @doc = '
> <ROOT>
> <Order OrderID="10250"/>
> <Order OrderID="10893"/>
> <Order OrderID="10937"/>
> <Order OrderID="10946"/>
> <Order OrderID="10392"/>
> <Order OrderID="10260"/>
> <Order OrderID="10378"/>
> <Order OrderID="10879"/>
> <Order OrderID="11008"/>
> <Order OrderID="11045"/>
> <Order OrderID="10715"/>
> <Order OrderID="11031"/>
> <Order OrderID="11059"/>
> </ROOT>'
>
> dbcc freeproccache
> dbcc dropcleanbuffers
>
> set @sd = getdate()
>
> select
> oh.orderid,
> oh.customerid,
> oh.orderdate
> from
> dbo.orders as oh
> inner join
> dbo.inline_split_me(@s) as a
> on oh.orderid = a.value
>
> set @ed = getdate()
>
> select datediff(millisecond, @sd, @ed)
>
> dbcc freeproccache
> dbcc dropcleanbuffers
>
> set @sd = getdate()
>
> exec sp_xml_preparedocument @idoc OUTPUT, @doc
>
> select
> oh.orderid,
> oh.customerid,
> oh.orderdate
> from
> dbo.orders as oh
> inner join
> openxml(@idoc, '/ROOT/Order', 1)
> with (OrderID int) as a
> on oh.orderid = a.orderid
>
> exec sp_xml_removedocument @idoc
>
> set @ed = getdate()
>
> select datediff(millisecond, @sd, @ed)
> go
>
> drop function inline_split_me
> go
>
> drop table dbo.number
> go
>
>
> Saludos,
>
>
> AMB
>
>
> "Maxi" wrote:
>
>> Ale, lo lei el articulo pero a ver: las otras alternativas no me parecen
>> muy buenas que digamos :S, te comento que estoy usando XML con grandes
>> datos
>> y funciona muy pero muy rapído de verdad. La ventaja a xml que le veo son
>> muchas
>>
>> 1) Usas un formato standard y aislas mucho el SP's
>> 2) La performance como te indique no se ve casi nada afectada, yo como te
>> dije lo uso mucho y en soft con muchas transacciones en un sistemas ERP
>> 3) Es muy simple de usar
>> 4) Es mucho mas seguro que usar SQL dinamico ;-)
>> 5) Dejas todo bien armadito para sql2005 sin mayores cambios
>>
>> De todas maneras agradesco tu articulo, pero como te indique yo uso XMl
>> en
>> sql desde hace un rato largo en sistemas criticos y la verdad que hasta
>> el
>> momento me parece la mejor solucion a pasar datos Array a un Sp's
>>
>>
>>
>> Maxi - Buenos Aires - Argentina
>> Desarrollador 3 Estrellas
>>
>> Msn_messager:
>> mail: Maxi.da[arroba]gmail.com
>>
>> "Alejandro Mesa" escribió en el
>> mensaje news:
>> > Maxi,
>> >
>> > Te invito a que leas el articulo ligado al link posteado. En el
>> > encontraras
>> > una muy buena explicacion sobre este tema, incluyendo tablas de
>> > comparacion
>> > entre los diferentes metodos.
>> >
>> >
>> > AMB
>> >
>> > "Maxi" wrote:
>> >
>> >> Hola, porque dices q no es optima, mira yo lo uso mucho y es muy
>> >> optima!!
>> >> en
>> >> que te basas o que experiencias has tenido con esto para indicar q no
>> >> es
>> >> optima?
>> >>
>> >>
>> >> Maxi - Buenos Aires - Argentina
>> >> Desarrollador 3 Estrellas
>> >>
>> >> Msn_messager:
>> >> mail: Maxi.da[arroba]gmail.com
>> >>
>> >> "Alejandro Mesa" escribió en
>> >> el
>> >> mensaje news:
>> >> > Nicolas Ibarra Salazar,
>> >> >
>> >> > Como indico Maxi, pudieras pasar los valores en un documento xml
>> >> > como
>> >> > parametro de entrada a un procedimiento almacenado. Esta opcion no
>> >> > es
>> >> > la
>> >> > mas
>> >> > optima, al menos en sql server 2000. Existen otras formas de simular
>> >> > arreglos
>> >> > en t-sql. Aca te paso un link donde podras leer sobre las multiples
>> >> > opciones
>> >> > que existen para hacer esto en sql server.
>> >> >
>> >> > Arrays and Lists in SQL Server
>> >> > http://www.sommarskog.se/arrays-in-sql.html
>> >> >
>> >> >
>> >> > AMB
>> >> >
>> >> > "Nicolas Ibarra Salazar" wrote:
>> >> >
>> >> >> En una SELECT, cómo hago para pasarle más de un valor proveniente
>> >> >> de