Ejemplo PVISTASSP con varios temas a debatir

24/10/2007 - 14:15 por Pablo Roca | Informe spam
Hola,

A ver, pongo un caso:

En una aplicación de gestion, queremos obtener tanto las ventas totales,
como las ventas de un centro de coste.

Requerimientos:

Arquitectura WebServices,
PC cliente
PC servidor con SQL server e IIS


Tablas, datos, vistas y SPs adjuntos a este mensaje
(y no me discutais de momento los nombres de los campos, pks o indices :))
para este ejemplo el como se calcula el total de ventas en las cabeceras de
albaranes es irrelevante


Ejecuciones posibles:

A. ventas totales, ordenadas por descripcion del centro de coste y nombre
del cliente

A1. con vistas:

SELECT * FROM [dbo].[v_ventas] ORDER BY ccodesc, clinom

A2. con SPs:

USE [pvistassp]
GO
EXEC [dbo].[usp_ventas]
GO


B. ventas de la central (la central siempre es AST, por definición)

B1. con vistas:

SELECT * FROM [dbo].[v_ventas] WHERE pk_ccocod = 'AST' ORDER BY ccodesc,
clinom

B2. con SPs:

USE [pvistassp]
GO
EXEC [dbo].[usp_ventas] @iccoste = N'AST'
GO

********************************
el cliente webservice se autentifica, etc .. y llama a la funcion ventas.
nuestro programa solo tiene que llanmar a ver las ventas, el como se hace es
cuestion de la capa de negocio.

Metalenguaje (capa de negocio), puesta por ejemplo con vistas, en el lado
del servidor (no me pidais que ponga un ejemplo detallado en C#)

public ventas (string tccentro)
if tccentro = ''
SELECT * FROM [dbo].[v_ventas] ORDER BY ccodesc, clinom
else
SELECT * FROM [dbo].[v_ventas] WHERE pk_ccocod = 'AST' ORDER BY ccodesc,
clinom
endif
return el dataset .. etc ...
********************************

Cuestiones a debatir:

1. ¿Porque esa capa de negocio? (esta no es cuestion, sino reflexión)

En Webservices es necesaria, llevarse la lógica de la consulta al winform
del cliente, lo único que hace es dispersar y difuminar la lógica de la
aplicación.

Soy de la opinión que en el lado de la capa de presentación debe haber el
mínimo código posible. Que debemos tener un sitio centralizado (webservice o
servidor o clase independiente implementada en el lado cliente) que tenga
los objetos y sus métodos bien identificados.

Si ponemos este codigo (o similar), por ejemplo directamente en el evento
clic de un boton consultar ventas. En caso de que fuera necesario consultar
las ventas en mas de un formulario, tendriamos que copiar y pegar dicho
codigo, de cada vez. El mantenimiento de esto empezaria a complicarse. Y
pienso que es una muy mala práctica de reutilización de codigo.

Este método facilita el poder intercambir el desarrollo entre WinForms,
WebForms, WebServices, aplicaciones de terceros desarrolladas en en lenguaje
Java, o x

2. ¿Con vistas o con SPs?

En este caso me dá que con vistas estaría mas optimizado. Fijaros en las
cuatro ejecuciones posibles y mirar el plan de ejecución dse cada una de
ellas.

No son iguales!

La ejecución B1 difiere de los otros planes de ejecución, que si son iguales
entre si. Por tanto se me ocurre pensar que las vistas no funcionan igual
que los SPs a nivel de rendimiento

3. Vistas con indices? Fijaros que en este ejemplo las vistas no tienen
indices (ya estan puestos en las tablas). Se gana algo poniendo indices
adicionales en las vistas?

4. La ejecución B1 ... ¿No está realmente haciendo dos SELECT?

5. ¿Manera de mejorar esta vista?



De momento no se me ocurre ninguna cuestión mas, pero bueno se agradecen
cualquier comentario que pueda plantear nuevas cuestiones.

Venga .. que empiece el debate amistoso. :)

Agradeceria que respondieras citando la cuestion (1,2,3 ...) .. y el ejemplo
de ejecución (B1, A1, ...)


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com


begin 666 pvistassp.zip
M4$L#!!0``@`(`-QF6#c[<EO0```"0!```.````=7-P7W9E;G1A<RYS<6QU
MC;$*PC 41><$\@]O4Q<71Q%:VZ<$2J)-`H*44FO!@C3%Q'Z_J6(7<7G#N_>>
M8Q3"N1]:YROG^H+1O624484:8J%X*4R6*9#B$XSOHY$:TY*G*#3?<<RGE-$D
MQU@C''*98&KR@+Y>;+$\/UU?#DT7',% HK:NK?,-=/6M>LQ7"]C ;,9HK!CMXIX''!E-0B;2"!WXZQ%.^ ZFZ6=!")XP^;5XZZM[XXJP(Y@I_-^LPWW8`J*)
M^U6\G2A21E]02P,$% `"``@`_6)8-S9A:<,\`@``% D``! ```!C<F5A<E]T
M86)L87,N<W%LU5;-;YLP%#\/B?_A'1.IG=I-/>[@@DFM$)MAHS9"R'((T]!8
MB +*WS_SE03(DDK+83UP\'O/]N_#SR;@&,+M/BU*513;R#1FS#0X%H H)Y(&
MKLN!T6/X>\ $MB6Q,17$(=CO9>M)'K)M0F>'A&G<WT.I5IF".-F4N[R =0)Q
M7I2):5@^1@*#0,^N!K)>Y='G,*YST<0T/H7;7U(/XWPC_5+MH\G4*E FH
MH-U5%3J]3HI8Y_=JUY1\>9AV>; 8Y<)'A H(O;ELUP;/)POD+V&.EV"Y`1?8
MQS:8QG!3Q"W3F+X2\0(334P2:N,W@&_ '.<.N$""<$$L+BGSL<467J#9=&DR
MJZ+2#CQ9[=-&D>NR5^GKSV76G-?5M M[:(9/XU/]:> -6FW/<#R6.$NUR$GQ
M%VG;[%'<+$TK;=--&4'CJEA.'N\>ARIG:6/"II'X:9S?Y+]/37AZZ)6,C.B0
M7+>B@?CAG%#92NW4)JF/^UZ35><]T77[4AT<4?OX78Y<[XRAO;VDWB9?%2/#
M3M)E7JI,%_S(<M6?/?2R97#5R9;:1W&R-8LR>B338 W)B?K5Y)Z3M[Y&./.%
MGB$%7GCV\V4A;)]Y$K]5J^DKN TRZA**;Z+5V:$W!LT]/^E27->D*O5
M.-O;`#5-ZP5;<]#/(_0ZR.DZZ/ Z.9J%YE(UTN3D&$U-P\>.5IQ:F ]>2Q@4
M5I N`&J@7$1Q=8WWDCK<]"-:]4$XS^HPJ5_Y+[2Z)3N_QG\LCE/%_P!02P,$
M% `"``@`BV58-VF%Y_5Y`0``%P4```D```!D871O<RYS<6R]4LMN@S 0O"/Q
M#[Z12"3*HU4//6V)A9!X1#9PB5!E# KJ. ^/ZN(6G:`Z>2^N)E/<S,/E8K
M(B^ED)5J2%&20G2J-0W32#@EY[YJ.]&V9]-P(YU<K4: 1G8BKP619=-=QH14
M;5=JE!=RRF+BA7%$3D6NLO5)#H^9:9#[69S.'^_X(%61$5M#BK*5V?(*2L%/
M*/_]AP4\MFRBKX1YP*WE@_4".&@]O)AW&-4F.U%7V(NRG7)T?1X\+?2G]F'K
MH%&?VL5H8&%M\&PMVSK28\3!6K[.PKA#1I=!X,U'N4=*8!2(0\.817/1/B&M
M#X3RF%'?G\WM,](ZP$+/`4Z.\.;?#-\&^F.B.,YQJ*+.Q44TY9#M44U,>$%@
MWXFKD_N>V4-<5Y4.12]5WHY!ISI1_[0X;/86*_=I"HPX$(,?N1'Fú^O=E,
MMN'/TL.2[W'AF!=0!B3%<0(*/UIW*'EG6VGDIY013@,(47?_+[K8:D[=)#Q\
MU_MR5W6C+U!+`P04``(`" #'95@WD3UN<*L#```2$0``# ```'9?õN=&%S
M+G-Q;-58;6_B.!#^7JG_P>H76HFBV$F ?JBT`9)\3I$NC>*:J02US6NI!$
MB<,=__[LO)0$0G>3574Z2X1H9CS/S.,Q]K"T=>"$.QHS',?A\^7%9^ORXO+"
MUA= ,^WIRES.9C:PS$PAQ-^6UD*?K*83W5Q,C:D^?]..Y[JVT,'35/\.'/<E
M>.XYN]6.^-PU=ZS98OY,'R^ &%S?P][+CN%>^-=JO0[6@=M-I?P]9D1\N21>
MYS*/<C\D%B\'PY+0#[9=8"\?KDM^\6[-`H:]&Z#9((OC\L*86P^@& =C,#5-
MGLI7:\J3`;7C$!O/N#9^<%].X"#^1=]Y.C7>/4K?G!=)%W+._=Q:/H+1GQ_
MJ:@%L;3Z'_H8Q/NX%X<K[+KD'T9\E[AA%(0D8GOPR<=;<F]V'NS5A.)-A+>/
MV">PTP6?=MA+A,J1="0CPY!N1TJ_?POA^O560XIQ*TF:QC^R;AA&%\">)/%J
M&9$-]<&$Q'3C/V8HE%-S#U(&,ZV & ?^*]TD$68T\-_TYTVXA51:!#-)`Q43
ME9+X>,K5]1=P#1U%>@:*@_@3I4_Y!MQ<%=-TW_TY-JS'EG^*#1Q5@ ,'J0*W
M(2SZ/5C4$E9N"<O3E#-816H!J]3#HE_)MM\"3VV)Q_/KM\'KM\13LM5LC#>H
MQX/OXCV!Z\9 P[9EFJZ;XL A+YK&>_*N?;D,^*Y0FF8)I;: :;DT3Q#"]@73
M%_NP<8:H3<6(#)OG)K<LSN;+IK1$.D.?MF9T1PY(;R89,?@8?C].1TLR(J
MO@YB/A9!>'3&S<@K*XM.LEW@%X_$53<EC<@CNU5<5:\OF8TN[@*L.KL<"E).
M%'E$LC(\48T"QH)MNK#H1#FGFQ]BHBH/JKI22MF8T#CT\-[P\":M]*%4U?/0
MQH&7;(_O`U5'1R1DEZA6) S0.1+Z2'Z'!%4Z2\(0HO^$A/R"V(J&N[,T#*1W
M6!BJ9UE ZMW'LU"\5G>F_6U6WI5'VQ8S7+MG'S'?S821:$)><>(Q$=/5^5^B
M++3OU&4_XJ.S*A6F&2DU4EXZTO]&7$_P.**<)UK/XQ$QL'J8Y>LI([5<.II'
M<<IB):"BM"&L%*&5L#!AZ7G=KS@)0][[I ="Q8U)_GX2K<ZI)SN(V&(?IAI9
M/˜D4NBU%WE8O Y"I)PM#^=8U"/91.J<JNMK$)^^N@`WK=Y9$<\B?&X>?-F
MC[_H#UJGFTOS;H\WC)W"$N:6HOLO[&!N5_P+T/F=9G(<)#X[-)3PHV+\%U!+
M`P04``(`" "#9E@W-H+C-PT!``!?`@``%0```'5S<%]V96YT87-T;W1A;&5S
M+G-Q;+60O6Z#,!1&YUKR.]RQE2)>H.I P$&.B)WZ9ZBB"#G @$H#DBG/WVM"
M$H94G>K%UF?[?,>VFL&A'QL_.._[(R69I(02S0S$0O-"V#S7(,5E(\3O5AJ6
M%CQEPO -9^JV2TFB6&P8[)5,6&H5HJM3=XP.W[XOQOJ,'4,WN+;V6!1K2M8L
MXWCY*7"%3*05!FFO`859SA(#"(A<>QH'%_6?15EV95>MIA37?JC#5-6^G+.V
MP9K:A\7]X"(\=U\KT';WO."ZL9RT7B#6<-'$_HV2.X!%/W A\+5;.2F'`0L/
M]'[H"F]+V7O\&VQV?8!KF^9&N[[HFB,C4]+N8?WQ#S^&=*E2U)WI?W&F*TRD
ME/P`4$L#!!0``@`(`,1F6#=Z.493, $``*$"```4````=7-P7W9E;G1A<V-E
M;G1R;RYS<6RUD5]KPC 4Q9\-Y#O<-Q7$ESV.P6H;74=-7/XPAI12T\+*.EM,
MU\^_6ZW:!V5/RT,23I+?.??&* ;;NBU<DSI7QY2L!"64**;!XRI,N(DB!8*?
M#CKYS0C-@B0,&-?A,F3R<DJ)+YFG&6RD\%E@)**S717/MS^N3MI\CQX6YT,5
M`R6C9VLKU^2PMY_I8?(PA2<8>TJ/*?$4)0NV"I$[ZBRY\(7A&HT>.Q?4(N9K
M0/8\+7=MD\[KKP1IMLIF1_5$[I8L=[;7R@*]<]=MKA<'XK[ZGH$RZ\F F[:V
MJ9JTG(*GX%0!^B^E6 ,,_"'D'!OQ*HZ1NP&#')C[9E8L>!#V*M^#]5EOX,JB
MN-#.%9UU9+R_,/R+.Q'Z;\!K*RG,!A8?_]!8I L98%4]_2_.\0GC`26_4$L!
M`A0`% `"``@`W&98-U9/MR6]````) $```X``````````0`@`````````'5S
M<%]V96YT87,N<W%L4$L!`A0`% `"``@`_6)8-S9A:<,\`@``% D``! `````
M`````0`@````Z0```&-R96%R7W1A8FQA<RYS<6Q02P$"% `4``(`" "+95@W
M:87G]7D!```7!0``"0`````````!`" ```!3`P``9&%T;W,N<W%L4$L!`A0`
M% `"``@`QV58-Y$];G"K`P``$A$```P``````````0`@````\P0``'9?õN
M=&%S+G-Q;%!+`0(4`!0``@`(`(-F6#<V@N,W#0$``%\"```5``````````$`
M( ```,@(``!U<W!?õN=&%S=&]T86QE<RYS<6Q02P$"% `4``(`" #$9E@W
M>CE&4S !``"A`@``% `````````!`" ````("@``=7-P7W9E;G1A<V-E;G1R
;;RYS<6Q02P4&``````8`!@!P`0``:@L`````
`
end

Preguntas similare

Leer las respuestas

#1 Pablo Roca
24/10/2007 - 19:30 | Informe spam
2. ¿Con vistas o con SPs?

En este caso me dá que con vistas estaría mas optimizado. Fijaros en las
cuatro ejecuciones posibles y mirar el plan de ejecución dse cada una de
ellas.



Leche, quería decir con SPs está mas optimizado.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com
Respuesta Responder a este mensaje
#2 Eladio Rincón
24/10/2007 - 19:49 | Informe spam
Hola,

1. Si a la capa de negocio.
2. SPs; hemos hablado bastante entre hoy y ayer del código dinámico, así que
no voy a comentar nada más.
3. Vistas indexadas; son eficientes precisamente para agrupaciones; sin
embargo, estarás con Standard edition por lo que para usar los índices de la
vista indexada tendras que usar la opción with noexpand.
4. No, cuando usas una vista lo que hace es pillar el código de la vista y
resolverlo con la consulta completa. Creo que tu confusión es que crees qeu
primero resuelve la vista, y luego aplica filtros. Las vistas no funcionan
así.


Por cierto, un error muy común con las vistas es implementar mega-vistas que
cruzan muchas tablas, cuando en realidad el caso que quieres implementar con
cruzar 3-4 tablas es suficiente. Pregunté a Alfredo sobre esto en el
anterior thread, pero no me respodió.


Saludos,

Saludos,

Eladio Rincón,
SQL Server MVP
http://blogs.solidq.com/es/elrincondeldba

"Pablo Roca" wrote in message
news:%
Hola,

A ver, pongo un caso:

En una aplicación de gestion, queremos obtener tanto las ventas totales,
como las ventas de un centro de coste.

Requerimientos:

Arquitectura WebServices,
PC cliente
PC servidor con SQL server e IIS


Tablas, datos, vistas y SPs adjuntos a este mensaje
(y no me discutais de momento los nombres de los campos, pks o indices :))
para este ejemplo el como se calcula el total de ventas en las cabeceras
de albaranes es irrelevante


Ejecuciones posibles:

A. ventas totales, ordenadas por descripcion del centro de coste y nombre
del cliente

A1. con vistas:

SELECT * FROM [dbo].[v_ventas] ORDER BY ccodesc, clinom

A2. con SPs:

USE [pvistassp]
GO
EXEC [dbo].[usp_ventas]
GO


B. ventas de la central (la central siempre es AST, por definición)

B1. con vistas:

SELECT * FROM [dbo].[v_ventas] WHERE pk_ccocod = 'AST' ORDER BY ccodesc,
clinom

B2. con SPs:

USE [pvistassp]
GO
EXEC [dbo].[usp_ventas] @iccoste = N'AST'
GO

********************************
el cliente webservice se autentifica, etc .. y llama a la funcion ventas.
nuestro programa solo tiene que llanmar a ver las ventas, el como se hace
es cuestion de la capa de negocio.

Metalenguaje (capa de negocio), puesta por ejemplo con vistas, en el lado
del servidor (no me pidais que ponga un ejemplo detallado en C#)

public ventas (string tccentro)
if tccentro = ''
SELECT * FROM [dbo].[v_ventas] ORDER BY ccodesc, clinom
else
SELECT * FROM [dbo].[v_ventas] WHERE pk_ccocod = 'AST' ORDER BY ccodesc,
clinom
endif
return el dataset .. etc ...
********************************

Cuestiones a debatir:

1. ¿Porque esa capa de negocio? (esta no es cuestion, sino reflexión)

En Webservices es necesaria, llevarse la lógica de la consulta al winform
del cliente, lo único que hace es dispersar y difuminar la lógica de la
aplicación.

Soy de la opinión que en el lado de la capa de presentación debe haber el
mínimo código posible. Que debemos tener un sitio centralizado (webservice
o servidor o clase independiente implementada en el lado cliente) que
tenga los objetos y sus métodos bien identificados.

Si ponemos este codigo (o similar), por ejemplo directamente en el evento
clic de un boton consultar ventas. En caso de que fuera necesario
consultar las ventas en mas de un formulario, tendriamos que copiar y
pegar dicho codigo, de cada vez. El mantenimiento de esto empezaria a
complicarse. Y pienso que es una muy mala práctica de reutilización de
codigo.

Este método facilita el poder intercambir el desarrollo entre WinForms,
WebForms, WebServices, aplicaciones de terceros desarrolladas en en
lenguaje Java, o x

2. ¿Con vistas o con SPs?

En este caso me dá que con vistas estaría mas optimizado. Fijaros en las
cuatro ejecuciones posibles y mirar el plan de ejecución dse cada una de
ellas.

No son iguales!

La ejecución B1 difiere de los otros planes de ejecución, que si son
iguales entre si. Por tanto se me ocurre pensar que las vistas no
funcionan igual que los SPs a nivel de rendimiento

3. Vistas con indices? Fijaros que en este ejemplo las vistas no tienen
indices (ya estan puestos en las tablas). Se gana algo poniendo indices
adicionales en las vistas?

4. La ejecución B1 ... ¿No está realmente haciendo dos SELECT?

5. ¿Manera de mejorar esta vista?



De momento no se me ocurre ninguna cuestión mas, pero bueno se agradecen
cualquier comentario que pueda plantear nuevas cuestiones.

Venga .. que empiece el debate amistoso. :)

Agradeceria que respondieras citando la cuestion (1,2,3 ...) .. y el
ejemplo de ejecución (B1, A1, ...)


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com


Respuesta Responder a este mensaje
#3 Pablo Roca
24/10/2007 - 20:05 | Informe spam
Hola Eladio,

1. Si a la capa de negocio.



De acuerdo con eso.

2. SPs; hemos hablado bastante entre hoy y ayer del código dinámico, así
que no voy a comentar nada más.



Tambien de acuerdo. Aunque admito que desde la capa de negocio se pueda
llamar a vistas, vale, este ejemplo no era muy bueno para empezar a decidir
entre vistas y SPs

Lo que pasa que al final o llegamos a una gran cantidad de vistas o de SPs
... y tampoco veo muy bien donde encontrar el equilibrio ahi.

3. Vistas indexadas; son eficientes precisamente para agrupaciones; sin
embargo, estarás con Standard edition por lo que para usar los índices de
la vista indexada tendras que usar la opción with noexpand.



Ahi ya tengo dudas ... los campos ya los tengo indexados en la tabla. ¿Es
necesario o se mejora algo repitiendo esa indexación en las vistas?

4. No, cuando usas una vista lo que hace es pillar el código de la vista y
resolverlo con la consulta completa. Creo que tu confusión es que crees
qeu primero resuelve la vista, y luego aplica filtros. Las vistas no
funcionan así.



Correcto, esa era mi confusión. De todos modos me choca que el plan de
ejecición varie solo en la B1. Revisaste los planes de ejecución? ¿Como los
ves?

Por cierto, un error muy común con las vistas es implementar mega-vistas
que cruzan muchas tablas, cuando en realidad el caso que quieres
implementar con cruzar 3-4 tablas es suficiente. Pregunté a Alfredo sobre
esto en el anterior thread, pero no me respodió.



Si, lo vi. Buen dato.

Gracias por mirarlo.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com
Respuesta Responder a este mensaje
#4 Alfredo Novoa
24/10/2007 - 20:49 | Informe spam
Hola,

On Wed, 24 Oct 2007 14:15:08 +0200, "Pablo Roca"
wrote:

Tablas, datos, vistas y SPs adjuntos a este mensaje
(y no me discutais de momento los nombres de los campos, pks o indices :))
para este ejemplo el como se calcula el total de ventas en las cabeceras de
albaranes es irrelevante


Ejecuciones posibles:

A. ventas totales, ordenadas por descripcion del centro de coste y nombre
del cliente

A1. con vistas:

SELECT * FROM [dbo].[v_ventas] ORDER BY ccodesc, clinom



Esto lo puedes encapsular en un componente y configurarlo en tiempo de
diseño.


A2. con SPs:

USE [pvistassp]
GO
EXEC [dbo].[usp_ventas]
GO



Este SP ejecuta a otro SP cosa que no me parece muy óptima.

De todas formas estos SP son de los menos malos que puede haber por
que lo único que hacen es ejecutar a una consulta. En realidado son
parecidos a las vistas pero con la gran desventaja de que no pueden
usarse en otras vistas o consultas como si fuesen tablas.

Mucho peor hubiera sido que te hubieses liado a crear triggers para
mantener los totales en una tabla como hace mucha gente.

el cliente webservice se autentifica, etc .. y llama a la funcion ventas.
nuestro programa solo tiene que llanmar a ver las ventas, el como se hace es
cuestion de la capa de negocio.

Metalenguaje (capa de negocio), puesta por ejemplo con vistas, en el lado
del servidor (no me pidais que ponga un ejemplo detallado en C#)

public ventas (string tccentro)
if tccentro = ''
SELECT * FROM [dbo].[v_ventas] ORDER BY ccodesc, clinom
else
SELECT * FROM [dbo].[v_ventas] WHERE pk_ccocod = 'AST' ORDER BY ccodesc,
clinom
endif
return el dataset .. etc ...



Supongo que hay un pequeño error con el parámetro del procedimiento
que no se usa.

Este código es feo y fácil de eliminar. Yo para estas cosas tengo
controles visuales que pueden filtrar tablas y generan el SQL
automáticamente.

Para esta automatización otra vez son mejores las vistas.

De todas formas aunque quieras hacerlo de esta forma ese código habría
que meterlo en un SP y sacarlo fuera de las aplicaciones.

Si hay que hacer un SP para eliminar una clase de negocio enconces
bienvenido sea :-)

********************************

Cuestiones a debatir:

1. ¿Porque esa capa de negocio? (esta no es cuestion, sino reflexión)

En Webservices es necesaria, llevarse la lógica de la consulta al winform
del cliente, lo único que hace es dispersar y difuminar la lógica de la
aplicación.



No es cierto. Si te lo curras un poco puedes hacer que el uso de
WebServices sea transparente y creo que lo deberías de hacer.

La aplicación debería de poder cambiar de WebServices a ADO.NET o a lo
que sea sin cambios o cambiando un parámetro en un archivo de
configuración.

Soy de la opinión que en el lado de la capa de presentación debe haber el
mínimo código posible.



Eso todos.

Que debemos tener un sitio centralizado (webservice o
servidor o clase independiente implementada en el lado cliente) que tenga
los objetos y sus métodos bien identificados.



Yo ya tengo mis tablas y mis SP en SQL Server bien organizados.

Este método facilita el poder intercambir el desarrollo entre WinForms,
WebForms, WebServices, aplicaciones de terceros desarrolladas en en lenguaje
Java, o x



Hay formas mejores como usar un proveedor ADO.NET que funcione a
través de un Web Service.

3. Vistas con indices? Fijaros que en este ejemplo las vistas no tienen
indices (ya estan puestos en las tablas). Se gana algo poniendo indices
adicionales en las vistas?



Si, claro. Puedes intercambiar velocidad por espacio. A veces vienen
muy bien las vistas con índices. Yo las uso para calcular los stocks
por ejemplo, por que para eso las vistas normales van muy lentas
cuando hay miles de entradas y salidas.

4. La ejecución B1 ... ¿No está realmente haciendo dos SELECT?



No, pero con usp_ventas estás haciendo dos EXEC.



Saludos
Alfredo
Respuesta Responder a este mensaje
#5 Pablo Roca
24/10/2007 - 21:54 | Informe spam
Hola Alfredo,

Esto lo puedes encapsular en un componente y configurarlo en tiempo de
diseño.



Si, claro, en un componente en la capa de negocio :)

A2. con SPs:

USE [pvistassp]
GO
EXEC [dbo].[usp_ventas]
GO



Este SP ejecuta a otro SP cosa que no me parece muy óptima.



Bueno, en este caso concreto no me salió distinto el plan de ejecucion entre

usp_ventascentro y usp_ventastotales

Si fuera distinto mi aproximación es mejor a que vaya en un solo SP que
pueda llegar a provocar planes de ejecución variables, ya que cachearia cada
uno de los SPs por separado. Metiendolo todo en un solo SP, tendriamos la
creación variable de planes de ejecución .. y eso segun leo si que
empeoraria el rendimiento.

Mirate este articulo que me recomendó Gustavo, que lo explica mejor:

Este buen artículo del MVP Brad McGehee es recomendado:
SQL Server Performance Tuning for Stored Procedures
http://www.sql-server-performance.c...es_p1.aspx


De todas formas estos SP son de los menos malos que puede haber por
que lo único que hacen es ejecutar a una consulta. En realidado son
parecidos a las vistas pero con la gran desventaja de que no pueden
usarse en otras vistas o consultas como si fuesen tablas.




En esto ultimo te doy la razón .. pero claro todo depende de como se vaya a
utilizar, creo que apilar y apilar vistas una detrás de otra tampoco tiene
mucho sentido y al final empeorará el rendimiento.

public ventas (string tccentro)
if tccentro = ''
SELECT * FROM [dbo].[v_ventas] ORDER BY ccodesc, clinom
else
SELECT * FROM [dbo].[v_ventas] WHERE pk_ccocod = 'AST' ORDER BY
ccodesc,
clinom
endif
return el dataset .. etc ...



Supongo que hay un pequeño error con el parámetro del procedimiento
que no se usa.





Pues si .. donde pone 'AST' debería poner tccentro.

Este código es feo y fácil de eliminar. Yo para estas cosas tengo
controles visuales que pueden filtrar tablas y generan el SQL
automáticamente.




Bueno feo es un argumento no demasiado técnico y absolutamente subjetivo :)

Vamos a lo que importa, lo meterias en controles visuales? bien .. antes de
contestar añado otra respuesta tuya

Este método facilita el poder intercambir el desarrollo entre WinForms,
WebForms, WebServices, aplicaciones de terceros desarrolladas en en
lenguaje
Java, o x



Hay formas mejores como usar un proveedor ADO.NET que funcione a
través de un Web Service.




Hay un gran problema en trabajar como tu dices. Pero que muy grande.

Te pongo un posible escenario a donde llegarias con esta filosofia.

ya que tu trabajas mayoritariamente con vistas ...

Tienes la capa de presentacion de tu aplicación con los controles visuales
que filtran tablas y negeran el SQL automaticamente.
Como tu aplicación necesita interoperabilidad con empresas externas les das
un acceso ADO.NET a tu WebService, y ellos acceden desde Java por ejemplo.
En la pagina web de tu compañia los directivos pueden consultar información
de ventas

Ok, ahora te vienen los directivos de la empresa con un requerimiento que
surge con el método empírico, que tu sabes que se utiliza mucho en las
empresas, y te dicen "las ventas deben estar ordenadas por codigo de centro
y no por la descripción del centro"

¿Que haces?

Teniendo la capa de negocio, lo cambias ahi y asunto arreglado (aunque use
vista o SP)

A tu modo, habrá que empezar a bucear donde se accede a que cosa para
cambiar la ordenación. Es decir a buscar en todos los formularios, en todos
los Web Forms, etc, etc!

Me parece una muy mala organización de como tienen que diseñarse una
aplicación.

Sin contar con los posibles riesgos de seguridad que estamos introduciendo
al dejar a un tercero acceder nuestra base de datos a traves de un puente
que hagamos con ADO.NET. Ya, ya .. me dirás que pondrias permisos en las
vistas y que solo podrian acceder a ellas etc .. pero yo quiero tener el
control de lo que pueda hacer esa empresa externa, y si por definición
empresarial las ventas se calculan de una manera (que hace la capa de
negocios) la empresa externa no tienen porque andar investigando que tenemos
en nuestra BBDD.

Poniendolo en la capa de negocio la empresa externa tiene cambiado
automáticamente el calculo de las ventas, solo tocando la capa de negocio.

A mayores en este caso, se incrementa la complejidad al tener que
redistrubuir otra vez entre todos los clientes la capa de presentación.

1. ¿Porque esa capa de negocio? (esta no es cuestion, sino reflexión)

En Webservices es necesaria, llevarse la lógica de la consulta al winform
del cliente, lo único que hace es dispersar y difuminar la lógica de la
aplicación.



No es cierto. Si te lo curras un poco puedes hacer que el uso de
WebServices sea transparente y creo que lo deberías de hacer.




Piensa que un Web Service lo puede consumir alguien externo a tu
organización. Pare ellos no necesito ser trasnparente sino dar exactamente y
nada mas que la información que se necesita.

Que debemos tener un sitio centralizado (webservice o
servidor o clase independiente implementada en el lado cliente) que tenga
los objetos y sus métodos bien identificados.



Yo ya tengo mis tablas y mis SP en SQL Server bien organizados.




Ya, pero el acceso a datos parece que no lo tienes, ya que confias en
controles dispersos a lo largo de formularios. Mal método a mi parecer.

3. Vistas con indices? Fijaros que en este ejemplo las vistas no tienen
indices (ya estan puestos en las tablas). Se gana algo poniendo indices
adicionales en las vistas?



Si, claro. Puedes intercambiar velocidad por espacio. A veces vienen
muy bien las vistas con índices. Yo las uso para calcular los stocks
por ejemplo, por que para eso las vistas normales van muy lentas
cuando hay miles de entradas y salidas.




Bien, esto no lo tenia claro, gracias por el dato.

4. La ejecución B1 ... ¿No está realmente haciendo dos SELECT?



No, pero con usp_ventas estás haciendo dos EXEC.




Ok, lo de los dos SELECT tampoco lo tenia claro.

Si puedo hacer dos EXEC, que no penaliza en absoluto (mirate el articulo que
te dije antes), eso es mejor que tener planes de ejecución variables que se
construyen al vuelo.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente Respuesta Tengo una respuesta
Search Busqueda sugerida