Personal Edition

Hola Maxi de nuevo,

Solo un par de detalles:
- Con respecto a la inclusión del CLR dentro de SQL 2005, acabo de
participar en el ISV Community Day de Microsoft y asisir a una charla sobre
este punto. Y lo que dejan claro es que no es la panacea, que no tenemos que
hacer ahora todo en C# o VB.NET, precisamente por eso por defecto está
desactivada la opción del CLR. Tiene sus limitaciones y sus ventajas, pero
hay que analizar cada caso en concreto. El futuro, nunca se sabe, Microsoft
nos sorprende día a día.
- En la ultima frase indicas que si tienes algo complejo lo sacas fuera de
SQL ¿Donde lo pones? ¿en el código del cliente? cada vez que cambies algo de
lógica distribuyes de nuevo todos los clientes, esto puede tener sentido con
Click Once o puede no tener sentido si en esa lógica está el hablar con
MSMQ, otros servidores, etc ¿No pondrás esa lógica en cada cliente? Teniendo
que abrir puerto o exponiendo otros servidores a toda la red.
- ¿Para sistemas mixtos es una buena solución abrir la base de datos a todo
el mundo?, todo aquel que quiera interactuar con el sistema debe conocer
todo el modelo de datos. Cada vez que el DBA detecte mediante análisis de
rendimiento que es necesario cambiar algo en una tabla es mejor avisar a
todo el mundo de que el modelo ha cambiado, en lugar de solo cambiar la
lógica que ofreces a los demas mediante WebService o COM+.
- Que pintan los WebServices en todo esto, que mejor forma de ofrecer
servicios a otros sistemas heterogeneos.
- Si te pones rigido con la auditoria y seguridad, no hay problemas,
implantas seguridad Windows, en lugar de mixta, que ademas es lo que
recomienda Microsoft. Implementas objetos de lógica de negocio en COM+,
WebService o Remoting (todos soportan autentificación Windows) y ya tienes
la seguridad y auditoria integrados.
- Con respecto a los 18' en comparación con segundos, sinceramente creo que
el componente no se desarrolló correctamente. Pero aquí no hay dudas, es
lógico hacer lógica en procedimientos almacenados y que sean los componentes
quien ejecuten esos procedimientos. En eso estamos de acuerdo.

Vuelvo a indicarte que creo que tenemos puntos de vista comunes, y que
sencillamente nos hemos empeñado en llevar cada uno la razón, a lo mejor con
el objetivo de conseguir el record de hilo mas largo nunca matenido por dos
personas.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Maxi" escribió en el mensaje
news:%

Hola, entrelineas ;-)

Hola Maxi,

ante todo comentarte que el inicio de este hilo era acerca de un sistema
pequeño para pocos usuarios, con un desarrollo realizado por una o pocos
personas y seguramente pocos recursos.
Con esta premisa antes todo hay que buscar la efectividad y rapidez en el
desarrollo, pero si es posible con visión de futuro hacia el cliente.

Tienes razon, era un sistema pequeño, pero si hacemos bien las cosas de
entrada seguro que no tendremos que volver a codificar ;-)

Ya se que se aplica en muchos proyectos y que a los desarrolladores les
simplifica la vida, pero no es una buena practica de programacion para
un servidor de base de datos hacerlo asi. Si debes convivir con otros
sistemas o el sistema a desarrollar llegara a ser de mision critica, vas
a entender lo que te comento ;-)

He desarrollado sistema que interactuan con otros sistemas y sistemas de
misión crítica y no entiendo lo que comentas, dime un caso concreto.

Si el sistema de de mision critica vas a necesitar otro tipo de auditorias
seguramente, porque a ese sistema lo pueden estar bombardenado de varios
tipos de aplicaciones, podria ser tu Com+, podria ser un Unix, etc, etc.
Si la auditoria la pones fuera entonces no estaras cubriendo todos los
casos de donde pueden disparar al sistema, por ej, que pasa si meten un
DTS y quieres auditar ello, o si alguien por consola hace algunas cosas!!
hay tareas que son externas al Com+ y debes auditarlas / controlarlas con
lo cual se te puede complicar mucho si tienes un solo usuario.

La cadena de conexión la encriptas pero no viaja encriptada por la red,
puedes utilizar programas snnifer que directamente te muestran los
usuarios y password de las conexiones de SQL Server que se producen en
una red.
Estoy totalmente a favor de utilizar sólo procedimientos almacenados
desde las aplicaciones, para evitar al máximo problemas con sentencias
SQL mal formadas o problemas de injección de código.
El tunning se puede realizar sin problemas en ambos ambientes, de una
forma u otra al final son llamadas a procedimientos/SQL que se realizan
desde un equipo u otro, y el diseño de la base de datos no se ve afectado
por una alternativa u otra, simplemente se realiza en tunning en función
de unas cargas de trabajo y listo.

Hola, estas equivocado en lo que respecta a tunning, debo preguntarte (y
no lo tomes a mal), alguna vez has hecho tunning? suponete que se detecta
un alto consumo del cpu y se quiere sacar un ranking de quien esta
consumiendo eso, como busco eso si solo tengo un solo usuario?

Si tambien tienes un solo usuario de alguna manera estas pasando
informacion al servidor de claves, quizas sea menor, pero lo estas
pasando. Ademas tambien en tu menu se logeo le vas a tener q preguntar el
user y la pass al usuario por mas q lo controles por la aplicacion, y esto
es tambien muy simple de detectar :-)

En parte tienes razón con lo que dices pero si lo aplicamos a grandes
sistemas, como te he comentado antes partimos de una pequeñas aplicación.
En este tipo de aplicaciones la auditoria se centra en saber que usuario
modificó un registro en último lugar, que usuario lo creo, etc. En cada
caso se monta un sistema de auditoria distinto, aunque se pueden optar
por patrones ya creados.
Pero estoy contigo que en sistema grandes es mejor aplicar otras
alternativas, aunque tambien te comento que la base de datos no es el
centro del universo, y se pueden establecer otros mecanismos externos.

Todo depende, como te dije antes, si auditas por fuera y a la base alguien
la tiene que pinchar por otro lado vas a estar en problemas, ademas pensar
que un sistema siempre sera pequeño es no ver un poco de escalabilidad ;-)
La base no es el universo, como tampoco lo son los desarrollos, pero la
base es el corazon donde se guarda los datos, que generalmente son
criticos para cualquier sistema. Hoy dia cuando tenemos un motor como sql
la base puede ser pinchada de varios lugares y no tener esto en la cabeza
puede llegar a ser un gran problema, que pasa si en lugar de poner una
regla en un constraint lo hago fuera? pues si mañana meto un DTS chau
regla :(

Aquí entran en juego otros factores como centralizar la lógica de negocio
de una aplicación en un único punto, para permitir cambios mas rápidos y
actualizaciones. Aunque en muchos casos no es posible aplicarlos.
En entornos con muchas conexiones a medida que crecen las conexiones es
necesario redimensionar el servidor, con arquitecturas balanceadas se
soluciona añadiendo nuevos equipos que actuan de front-end.

Aja, es este el punto, donde ponemos las reglas? si son complejas usaria
un lenguaje de programacion mas potente que t-sql, pero sino las pondria
en t-sql, son mas eficientes y tambien estan en un solo sitio y muy simple
de modificar.
Ademas si vemos un poco lo que nos prepara el futuro, te daras cuenta que
una de las grandes modificaciones a sql2005 es permitir usar el CLR
dentro, que raro no? para que darle mas poder de programacion a un motor
de base de datos si la idea es sacar todo fuera? no te parece que se esta
yendo hacia otro lado?

Y te aseguro que si utilizas las librerias C++ de acceso a SQL Server en
modo nativo va más rapido aún, por que te quitas la capa
ADO/ADO.NET/ODBC/etc de encima, pero esas pruebas aislados indican lo que
es evidente, un programa en ensamblador va mas rapido que uno en VB, pero
cuento cuesta hacer una aplicación en ASM y cuanto en VB?
Creo que has cometido un error antes por que has puesto 18min cuando te
referias a segundos.
Pero has verificado si estaban activadas las transacciones distribuidas
en COM+ para ese componente, que normalmente estan por defecto.
Por otro lado con eso no mides escalabilidad, sino rendimiento, la
escalabilidad se mide cuando en lugar de realizar eso desde un equipo lo
haces desde 200 sobre el mismo servidor de bases de datos.

Aja, no he cometido error, eran 18' y no segundos, porque para hacerlos
desde el com+ y usando patrones y toda esa yerba, se tuvo que desarrollar
el proceso registro a registro y llamar tantas veces como se necesitaba,
con lo cual el proceso tardo mucho mas y ademas mientras la base crecia se
multiplicaba de forma proporcional el tiempo. Esto es rendimiendo cierto,
pero tambien es Escalabilidad, porque si ese proceso esta en produccion y
con 100 registros funciona, pero en un años hay 100.000 y ya deja de
funcionar o hace poner todo lento, entonces estamos ante un problema de
escalabilidad que afecta el rendimiento :-)

Para concluir simplemente decirte que son dos puntos de visión sobre una
forma de hacer las cosas, y que en cada caso se puede aplicar una forma u
otra. Hasta hace poco era muy complejo pasar de una arquitectura a otra,
la plataforma .NET está facilitando hoy en día todo esto.

Si, son 2 maneras distinas de hacer las cosas, yo no uso ni una ni otra,
balanceo y uso de cada herramienta lo mejor. Si la logica es compleja la
saco fuera, si la logica es simple la dejo en mi Sp's :-)

Un abrazo y un gusto poder compartir esto contigo !!!

Nos vemos


Salu2
Maxi

Hola Miguel, :-)

- En la ultima frase indicas que si tienes algo complejo lo sacas fuera de
SQL ¿Donde lo pones? ¿en el código del cliente? cada vez que cambies algo
de lógica distribuyes de nuevo todos los clientes, esto puede tener
sentido con Click Once o puede no tener sentido si en esa lógica está el
hablar con MSMQ, otros servidores, etc ¿No pondrás esa lógica en cada
cliente? Teniendo que abrir puerto o exponiendo otros servidores a toda la
red.

Depende, generalmente tengo un servidor donde uso un appblock para detectar
assemblis nuevos y se pueden ejecutar de forma local en el cliente. El
cliente tiene los componentes.

- ¿Para sistemas mixtos es una buena solución abrir la base de datos a
todo el mundo?, todo aquel que quiera interactuar con el sistema debe
conocer todo el modelo de datos. Cada vez que el DBA detecte mediante
análisis de rendimiento que es necesario cambiar algo en una tabla es
mejor avisar a todo el mundo de que el modelo ha cambiado, en lugar de
solo cambiar la lógica que ofreces a los demas mediante WebService o COM+.

Sip, porque la base no es propiedad de una aplicacion, la base es propiedad
de una organizacion y por ej esta organizaciom podria hasta tener un depto
de sistemas que se encarge de hacer desarrollos. Eso de conocer el contenido
es cierto, pero si haces bien las cosas y armas los diccionarios entonces no
hay drama

- Si te pones rigido con la auditoria y seguridad, no hay problemas,
implantas seguridad Windows, en lugar de mixta, que ademas es lo que
recomienda Microsoft. Implementas objetos de lógica de negocio en COM+,
WebService o Remoting (todos soportan autentificación Windows) y ya tienes
la seguridad y auditoria integrados.

Si, pero creo q no comprendes aun el tema :(, sea windows o mixta en tus
ejemplos usas un solo usuario para todo, con lo cual ya perdes el control

- Con respecto a los 18' en comparación con segundos, sinceramente creo
que el componente no se desarrolló correctamente. Pero aquí no hay dudas,
es lógico hacer lógica en procedimientos almacenados y que sean los
componentes quien ejecuten esos procedimientos. En eso estamos de acuerdo.

Me alegro que estemos de acuerdo :-)

Vuelvo a indicarte que creo que tenemos puntos de vista comunes, y que
sencillamente nos hemos empeñado en llevar cada uno la razón, a lo mejor
con el objetivo de conseguir el record de hilo mas largo nunca matenido
por dos personas.

Es posible, pero los que estan aca saben que no me gusta escribir lineas sin
sentido, he tenido hilos mas largos que este te lo aseguro ;-).

Un abrazo




"Miguel Angel Campos" <SPAMmacampos ARRUBA .idesarrollaSPAM.com> escribió en
el mensaje news:e%

Hola Maxi de nuevo,

Solo un par de detalles:
- Con respecto a la inclusión del CLR dentro de SQL 2005, acabo de
participar en el ISV Community Day de Microsoft y asisir a una charla
sobre este punto. Y lo que dejan claro es que no es la panacea, que no
tenemos que hacer ahora todo en C# o VB.NET, precisamente por eso por
defecto está desactivada la opción del CLR. Tiene sus limitaciones y sus
ventajas, pero hay que analizar cada caso en concreto. El futuro, nunca se
sabe, Microsoft nos sorprende día a día.
- En la ultima frase indicas que si tienes algo complejo lo sacas fuera de
SQL ¿Donde lo pones? ¿en el código del cliente? cada vez que cambies algo
de lógica distribuyes de nuevo todos los clientes, esto puede tener
sentido con Click Once o puede no tener sentido si en esa lógica está el
hablar con MSMQ, otros servidores, etc ¿No pondrás esa lógica en cada
cliente? Teniendo que abrir puerto o exponiendo otros servidores a toda la
red.
- ¿Para sistemas mixtos es una buena solución abrir la base de datos a
todo el mundo?, todo aquel que quiera interactuar con el sistema debe
conocer todo el modelo de datos. Cada vez que el DBA detecte mediante
análisis de rendimiento que es necesario cambiar algo en una tabla es
mejor avisar a todo el mundo de que el modelo ha cambiado, en lugar de
solo cambiar la lógica que ofreces a los demas mediante WebService o COM+.
- Que pintan los WebServices en todo esto, que mejor forma de ofrecer
servicios a otros sistemas heterogeneos.
- Si te pones rigido con la auditoria y seguridad, no hay problemas,
implantas seguridad Windows, en lugar de mixta, que ademas es lo que
recomienda Microsoft. Implementas objetos de lógica de negocio en COM+,
WebService o Remoting (todos soportan autentificación Windows) y ya tienes
la seguridad y auditoria integrados.
- Con respecto a los 18' en comparación con segundos, sinceramente creo
que el componente no se desarrolló correctamente. Pero aquí no hay dudas,
es lógico hacer lógica en procedimientos almacenados y que sean los
componentes quien ejecuten esos procedimientos. En eso estamos de acuerdo.

Vuelvo a indicarte que creo que tenemos puntos de vista comunes, y que
sencillamente nos hemos empeñado en llevar cada uno la razón, a lo mejor
con el objetivo de conseguir el record de hilo mas largo nunca matenido
por dos personas.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Maxi" escribió en el mensaje
news:%

Hola, entrelineas ;-)

Hola Maxi,

ante todo comentarte que el inicio de este hilo era acerca de un sistema
pequeño para pocos usuarios, con un desarrollo realizado por una o pocos
personas y seguramente pocos recursos.
Con esta premisa antes todo hay que buscar la efectividad y rapidez en
el desarrollo, pero si es posible con visión de futuro hacia el cliente.

Tienes razon, era un sistema pequeño, pero si hacemos bien las cosas de
entrada seguro que no tendremos que volver a codificar ;-)

Ya se que se aplica en muchos proyectos y que a los desarrolladores les
simplifica la vida, pero no es una buena practica de programacion para
un servidor de base de datos hacerlo asi. Si debes convivir con otros
sistemas o el sistema a desarrollar llegara a ser de mision critica,
vas a entender lo que te comento ;-)

He desarrollado sistema que interactuan con otros sistemas y sistemas de
misión crítica y no entiendo lo que comentas, dime un caso concreto.

Si el sistema de de mision critica vas a necesitar otro tipo de
auditorias seguramente, porque a ese sistema lo pueden estar bombardenado
de varios tipos de aplicaciones, podria ser tu Com+, podria ser un Unix,
etc, etc. Si la auditoria la pones fuera entonces no estaras cubriendo
todos los casos de donde pueden disparar al sistema, por ej, que pasa si
meten un DTS y quieres auditar ello, o si alguien por consola hace
algunas cosas!! hay tareas que son externas al Com+ y debes auditarlas /
controlarlas con lo cual se te puede complicar mucho si tienes un solo
usuario.

La cadena de conexión la encriptas pero no viaja encriptada por la red,
puedes utilizar programas snnifer que directamente te muestran los
usuarios y password de las conexiones de SQL Server que se producen en
una red.
Estoy totalmente a favor de utilizar sólo procedimientos almacenados
desde las aplicaciones, para evitar al máximo problemas con sentencias
SQL mal formadas o problemas de injección de código.
El tunning se puede realizar sin problemas en ambos ambientes, de una
forma u otra al final son llamadas a procedimientos/SQL que se realizan
desde un equipo u otro, y el diseño de la base de datos no se ve
afectado por una alternativa u otra, simplemente se realiza en tunning
en función de unas cargas de trabajo y listo.

Hola, estas equivocado en lo que respecta a tunning, debo preguntarte (y
no lo tomes a mal), alguna vez has hecho tunning? suponete que se detecta
un alto consumo del cpu y se quiere sacar un ranking de quien esta
consumiendo eso, como busco eso si solo tengo un solo usuario?

Si tambien tienes un solo usuario de alguna manera estas pasando
informacion al servidor de claves, quizas sea menor, pero lo estas
pasando. Ademas tambien en tu menu se logeo le vas a tener q preguntar el
user y la pass al usuario por mas q lo controles por la aplicacion, y
esto es tambien muy simple de detectar :-)

En parte tienes razón con lo que dices pero si lo aplicamos a grandes
sistemas, como te he comentado antes partimos de una pequeñas
aplicación. En este tipo de aplicaciones la auditoria se centra en saber
que usuario modificó un registro en último lugar, que usuario lo creo,
etc. En cada caso se monta un sistema de auditoria distinto, aunque se
pueden optar por patrones ya creados.
Pero estoy contigo que en sistema grandes es mejor aplicar otras
alternativas, aunque tambien te comento que la base de datos no es el
centro del universo, y se pueden establecer otros mecanismos externos.

Todo depende, como te dije antes, si auditas por fuera y a la base
alguien la tiene que pinchar por otro lado vas a estar en problemas,
ademas pensar que un sistema siempre sera pequeño es no ver un poco de
escalabilidad ;-)
La base no es el universo, como tampoco lo son los desarrollos, pero la
base es el corazon donde se guarda los datos, que generalmente son
criticos para cualquier sistema. Hoy dia cuando tenemos un motor como sql
la base puede ser pinchada de varios lugares y no tener esto en la cabeza
puede llegar a ser un gran problema, que pasa si en lugar de poner una
regla en un constraint lo hago fuera? pues si mañana meto un DTS chau
regla :(

Aquí entran en juego otros factores como centralizar la lógica de
negocio de una aplicación en un único punto, para permitir cambios mas
rápidos y actualizaciones. Aunque en muchos casos no es posible
aplicarlos.
En entornos con muchas conexiones a medida que crecen las conexiones es
necesario redimensionar el servidor, con arquitecturas balanceadas se
soluciona añadiendo nuevos equipos que actuan de front-end.

Aja, es este el punto, donde ponemos las reglas? si son complejas usaria
un lenguaje de programacion mas potente que t-sql, pero sino las pondria
en t-sql, son mas eficientes y tambien estan en un solo sitio y muy
simple de modificar.
Ademas si vemos un poco lo que nos prepara el futuro, te daras cuenta que
una de las grandes modificaciones a sql2005 es permitir usar el CLR
dentro, que raro no? para que darle mas poder de programacion a un motor
de base de datos si la idea es sacar todo fuera? no te parece que se esta
yendo hacia otro lado?

Y te aseguro que si utilizas las librerias C++ de acceso a SQL Server en
modo nativo va más rapido aún, por que te quitas la capa
ADO/ADO.NET/ODBC/etc de encima, pero esas pruebas aislados indican lo
que es evidente, un programa en ensamblador va mas rapido que uno en VB,
pero cuento cuesta hacer una aplicación en ASM y cuanto en VB?
Creo que has cometido un error antes por que has puesto 18min cuando te
referias a segundos.
Pero has verificado si estaban activadas las transacciones distribuidas
en COM+ para ese componente, que normalmente estan por defecto.
Por otro lado con eso no mides escalabilidad, sino rendimiento, la
escalabilidad se mide cuando en lugar de realizar eso desde un equipo lo
haces desde 200 sobre el mismo servidor de bases de datos.

Aja, no he cometido error, eran 18' y no segundos, porque para hacerlos
desde el com+ y usando patrones y toda esa yerba, se tuvo que desarrollar
el proceso registro a registro y llamar tantas veces como se necesitaba,
con lo cual el proceso tardo mucho mas y ademas mientras la base crecia
se multiplicaba de forma proporcional el tiempo. Esto es rendimiendo
cierto, pero tambien es Escalabilidad, porque si ese proceso esta en
produccion y con 100 registros funciona, pero en un años hay 100.000 y ya
deja de funcionar o hace poner todo lento, entonces estamos ante un
problema de escalabilidad que afecta el rendimiento :-)

Para concluir simplemente decirte que son dos puntos de visión sobre una
forma de hacer las cosas, y que en cada caso se puede aplicar una forma
u otra. Hasta hace poco era muy complejo pasar de una arquitectura a
otra, la plataforma .NET está facilitando hoy en día todo esto.

Si, son 2 maneras distinas de hacer las cosas, yo no uso ni una ni otra,
balanceo y uso de cada herramienta lo mejor. Si la logica es compleja la
saco fuera, si la logica es simple la dejo en mi Sp's :-)

Un abrazo y un gusto poder compartir esto contigo !!!

Nos vemos


Salu2
Maxi

Hola de nuevo,

con respecto a la seguridad de window no es un unico usuario, sino el
usuario que inicia la aplicación, si hablamos de una aplicación en windows,
si hablamos de una aplicación Web cambia la cosa por que depende de la
configuración establecida.

Con respecto al modelo de datos vuelves al caso de aplicaciones grandes, de
grandes organizaciones. Te recuerdo que estamos hablando de pequeñas
organizaciones que tienen que tener la mayor flexibilidad para interactuar
con otros componentes. Sin departamentos de DBA ni nada por el estilo.

Cambiando de tema, ¿que experiencias has tenido con UpdaterBlock? de
mientras que llega OnceClick es lo que hay y no lo he probado aún, y tengo
un desarrollo que necesita algo similar. Aunque esta pregunta no es de este
foro ahora que caigo.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Maxi" escribió en el mensaje
news:%

Hola Miguel, :-)

- En la ultima frase indicas que si tienes algo complejo lo sacas fuera
de SQL ¿Donde lo pones? ¿en el código del cliente? cada vez que cambies
algo de lógica distribuyes de nuevo todos los clientes, esto puede tener
sentido con Click Once o puede no tener sentido si en esa lógica está el
hablar con MSMQ, otros servidores, etc ¿No pondrás esa lógica en cada
cliente? Teniendo que abrir puerto o exponiendo otros servidores a toda
la red.

Depende, generalmente tengo un servidor donde uso un appblock para
detectar assemblis nuevos y se pueden ejecutar de forma local en el
cliente. El cliente tiene los componentes.

- ¿Para sistemas mixtos es una buena solución abrir la base de datos a
todo el mundo?, todo aquel que quiera interactuar con el sistema debe
conocer todo el modelo de datos. Cada vez que el DBA detecte mediante
análisis de rendimiento que es necesario cambiar algo en una tabla es
mejor avisar a todo el mundo de que el modelo ha cambiado, en lugar de
solo cambiar la lógica que ofreces a los demas mediante WebService o
COM+.

Sip, porque la base no es propiedad de una aplicacion, la base es
propiedad de una organizacion y por ej esta organizaciom podria hasta
tener un depto de sistemas que se encarge de hacer desarrollos. Eso de
conocer el contenido es cierto, pero si haces bien las cosas y armas los
diccionarios entonces no hay drama

- Si te pones rigido con la auditoria y seguridad, no hay problemas,
implantas seguridad Windows, en lugar de mixta, que ademas es lo que
recomienda Microsoft. Implementas objetos de lógica de negocio en COM+,
WebService o Remoting (todos soportan autentificación Windows) y ya
tienes la seguridad y auditoria integrados.

Si, pero creo q no comprendes aun el tema :(, sea windows o mixta en tus
ejemplos usas un solo usuario para todo, con lo cual ya perdes el control

- Con respecto a los 18' en comparación con segundos, sinceramente creo
que el componente no se desarrolló correctamente. Pero aquí no hay dudas,
es lógico hacer lógica en procedimientos almacenados y que sean los
componentes quien ejecuten esos procedimientos. En eso estamos de
acuerdo.

Me alegro que estemos de acuerdo :-)

Vuelvo a indicarte que creo que tenemos puntos de vista comunes, y que
sencillamente nos hemos empeñado en llevar cada uno la razón, a lo mejor
con el objetivo de conseguir el record de hilo mas largo nunca matenido
por dos personas.

Es posible, pero los que estan aca saben que no me gusta escribir lineas
sin sentido, he tenido hilos mas largos que este te lo aseguro ;-).

Un abrazo




"Miguel Angel Campos" <SPAMmacampos ARRUBA .idesarrollaSPAM.com> escribió
en el mensaje news:e%

Hola Maxi de nuevo,

Solo un par de detalles:
- Con respecto a la inclusión del CLR dentro de SQL 2005, acabo de
participar en el ISV Community Day de Microsoft y asisir a una charla
sobre este punto. Y lo que dejan claro es que no es la panacea, que no
tenemos que hacer ahora todo en C# o VB.NET, precisamente por eso por
defecto está desactivada la opción del CLR. Tiene sus limitaciones y sus
ventajas, pero hay que analizar cada caso en concreto. El futuro, nunca
se sabe, Microsoft nos sorprende día a día.
- En la ultima frase indicas que si tienes algo complejo lo sacas fuera
de SQL ¿Donde lo pones? ¿en el código del cliente? cada vez que cambies
algo de lógica distribuyes de nuevo todos los clientes, esto puede tener
sentido con Click Once o puede no tener sentido si en esa lógica está el
hablar con MSMQ, otros servidores, etc ¿No pondrás esa lógica en cada
cliente? Teniendo que abrir puerto o exponiendo otros servidores a toda
la red.
- ¿Para sistemas mixtos es una buena solución abrir la base de datos a
todo el mundo?, todo aquel que quiera interactuar con el sistema debe
conocer todo el modelo de datos. Cada vez que el DBA detecte mediante
análisis de rendimiento que es necesario cambiar algo en una tabla es
mejor avisar a todo el mundo de que el modelo ha cambiado, en lugar de
solo cambiar la lógica que ofreces a los demas mediante WebService o
COM+.
- Que pintan los WebServices en todo esto, que mejor forma de ofrecer
servicios a otros sistemas heterogeneos.
- Si te pones rigido con la auditoria y seguridad, no hay problemas,
implantas seguridad Windows, en lugar de mixta, que ademas es lo que
recomienda Microsoft. Implementas objetos de lógica de negocio en COM+,
WebService o Remoting (todos soportan autentificación Windows) y ya
tienes la seguridad y auditoria integrados.
- Con respecto a los 18' en comparación con segundos, sinceramente creo
que el componente no se desarrolló correctamente. Pero aquí no hay dudas,
es lógico hacer lógica en procedimientos almacenados y que sean los
componentes quien ejecuten esos procedimientos. En eso estamos de
acuerdo.

Vuelvo a indicarte que creo que tenemos puntos de vista comunes, y que
sencillamente nos hemos empeñado en llevar cada uno la razón, a lo mejor
con el objetivo de conseguir el record de hilo mas largo nunca matenido
por dos personas.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Maxi" escribió en el mensaje
news:%

Hola, entrelineas ;-)

Hola Maxi,

ante todo comentarte que el inicio de este hilo era acerca de un
sistema pequeño para pocos usuarios, con un desarrollo realizado por
una o pocos personas y seguramente pocos recursos.
Con esta premisa antes todo hay que buscar la efectividad y rapidez en
el desarrollo, pero si es posible con visión de futuro hacia el
cliente.

Tienes razon, era un sistema pequeño, pero si hacemos bien las cosas de
entrada seguro que no tendremos que volver a codificar ;-)

Ya se que se aplica en muchos proyectos y que a los desarrolladores
les simplifica la vida, pero no es una buena practica de programacion
para un servidor de base de datos hacerlo asi. Si debes convivir con
otros sistemas o el sistema a desarrollar llegara a ser de mision
critica, vas a entender lo que te comento ;-)

He desarrollado sistema que interactuan con otros sistemas y sistemas
de misión crítica y no entiendo lo que comentas, dime un caso concreto.

Si el sistema de de mision critica vas a necesitar otro tipo de
auditorias seguramente, porque a ese sistema lo pueden estar
bombardenado de varios tipos de aplicaciones, podria ser tu Com+, podria
ser un Unix, etc, etc. Si la auditoria la pones fuera entonces no
estaras cubriendo todos los casos de donde pueden disparar al sistema,
por ej, que pasa si meten un DTS y quieres auditar ello, o si alguien
por consola hace algunas cosas!! hay tareas que son externas al Com+ y
debes auditarlas / controlarlas con lo cual se te puede complicar mucho
si tienes un solo usuario.

La cadena de conexión la encriptas pero no viaja encriptada por la red,
puedes utilizar programas snnifer que directamente te muestran los
usuarios y password de las conexiones de SQL Server que se producen en
una red.
Estoy totalmente a favor de utilizar sólo procedimientos almacenados
desde las aplicaciones, para evitar al máximo problemas con sentencias
SQL mal formadas o problemas de injección de código.
El tunning se puede realizar sin problemas en ambos ambientes, de una
forma u otra al final son llamadas a procedimientos/SQL que se realizan
desde un equipo u otro, y el diseño de la base de datos no se ve
afectado por una alternativa u otra, simplemente se realiza en tunning
en función de unas cargas de trabajo y listo.

Hola, estas equivocado en lo que respecta a tunning, debo preguntarte (y
no lo tomes a mal), alguna vez has hecho tunning? suponete que se
detecta un alto consumo del cpu y se quiere sacar un ranking de quien
esta consumiendo eso, como busco eso si solo tengo un solo usuario?

Si tambien tienes un solo usuario de alguna manera estas pasando
informacion al servidor de claves, quizas sea menor, pero lo estas
pasando. Ademas tambien en tu menu se logeo le vas a tener q preguntar
el user y la pass al usuario por mas q lo controles por la aplicacion, y
esto es tambien muy simple de detectar :-)

En parte tienes razón con lo que dices pero si lo aplicamos a grandes
sistemas, como te he comentado antes partimos de una pequeñas
aplicación. En este tipo de aplicaciones la auditoria se centra en
saber que usuario modificó un registro en último lugar, que usuario lo
creo, etc. En cada caso se monta un sistema de auditoria distinto,
aunque se pueden optar por patrones ya creados.
Pero estoy contigo que en sistema grandes es mejor aplicar otras
alternativas, aunque tambien te comento que la base de datos no es el
centro del universo, y se pueden establecer otros mecanismos externos.

Todo depende, como te dije antes, si auditas por fuera y a la base
alguien la tiene que pinchar por otro lado vas a estar en problemas,
ademas pensar que un sistema siempre sera pequeño es no ver un poco de
escalabilidad ;-)
La base no es el universo, como tampoco lo son los desarrollos, pero la
base es el corazon donde se guarda los datos, que generalmente son
criticos para cualquier sistema. Hoy dia cuando tenemos un motor como
sql la base puede ser pinchada de varios lugares y no tener esto en la
cabeza puede llegar a ser un gran problema, que pasa si en lugar de
poner una regla en un constraint lo hago fuera? pues si mañana meto un
DTS chau regla :(

Aquí entran en juego otros factores como centralizar la lógica de
negocio de una aplicación en un único punto, para permitir cambios mas
rápidos y actualizaciones. Aunque en muchos casos no es posible
aplicarlos.
En entornos con muchas conexiones a medida que crecen las conexiones es
necesario redimensionar el servidor, con arquitecturas balanceadas se
soluciona añadiendo nuevos equipos que actuan de front-end.

Aja, es este el punto, donde ponemos las reglas? si son complejas usaria
un lenguaje de programacion mas potente que t-sql, pero sino las pondria
en t-sql, son mas eficientes y tambien estan en un solo sitio y muy
simple de modificar.
Ademas si vemos un poco lo que nos prepara el futuro, te daras cuenta
que una de las grandes modificaciones a sql2005 es permitir usar el CLR
dentro, que raro no? para que darle mas poder de programacion a un motor
de base de datos si la idea es sacar todo fuera? no te parece que se
esta yendo hacia otro lado?

Y te aseguro que si utilizas las librerias C++ de acceso a SQL Server
en modo nativo va más rapido aún, por que te quitas la capa
ADO/ADO.NET/ODBC/etc de encima, pero esas pruebas aislados indican lo
que es evidente, un programa en ensamblador va mas rapido que uno en
VB, pero cuento cuesta hacer una aplicación en ASM y cuanto en VB?
Creo que has cometido un error antes por que has puesto 18min cuando te
referias a segundos.
Pero has verificado si estaban activadas las transacciones distribuidas
en COM+ para ese componente, que normalmente estan por defecto.
Por otro lado con eso no mides escalabilidad, sino rendimiento, la
escalabilidad se mide cuando en lugar de realizar eso desde un equipo
lo haces desde 200 sobre el mismo servidor de bases de datos.

Aja, no he cometido error, eran 18' y no segundos, porque para hacerlos
desde el com+ y usando patrones y toda esa yerba, se tuvo que
desarrollar el proceso registro a registro y llamar tantas veces como se
necesitaba, con lo cual el proceso tardo mucho mas y ademas mientras la
base crecia se multiplicaba de forma proporcional el tiempo. Esto es
rendimiendo cierto, pero tambien es Escalabilidad, porque si ese proceso
esta en produccion y con 100 registros funciona, pero en un años hay
100.000 y ya deja de funcionar o hace poner todo lento, entonces estamos
ante un problema de escalabilidad que afecta el rendimiento :-)

Para concluir simplemente decirte que son dos puntos de visión sobre
una forma de hacer las cosas, y que en cada caso se puede aplicar una
forma u otra. Hasta hace poco era muy complejo pasar de una
arquitectura a otra, la plataforma .NET está facilitando hoy en día
todo esto.

Si, son 2 maneras distinas de hacer las cosas, yo no uso ni una ni otra,
balanceo y uso de cada herramienta lo mejor. Si la logica es compleja la
saco fuera, si la logica es simple la dejo en mi Sp's :-)

Un abrazo y un gusto poder compartir esto contigo !!!

Nos vemos


Salu2
Maxi

Hola Miguel

con respecto a la seguridad de window no es un unico usuario, sino el
usuario que inicia la aplicación, si hablamos de una aplicación en
windows, si hablamos de una aplicación Web cambia la cosa por que depende
de la configuración establecida.

A ver, si tengo 5 maquinas distintas, cuantas conexiones tendre?

Con respecto al modelo de datos vuelves al caso de aplicaciones grandes,
de grandes organizaciones. Te recuerdo que estamos hablando de pequeñas
organizaciones que tienen que tener la mayor flexibilidad para interactuar
con otros componentes. Sin departamentos de DBA ni nada por el estilo.

No te creas, hay organizaciones ´pymes q no tienen un dba pero necesitan
tener un control mejor de la base, o lo q es peor aun puede ser que hoy sea
una pequeña empresa y el dia de mañana tiene un dba o cosa simil, ahi
pues

Cambiando de tema, ¿que experiencias has tenido con UpdaterBlock? de
mientras que llega OnceClick es lo que hay y no lo he probado aún, y tengo
un desarrollo que necesita algo similar. Aunque esta pregunta no es de
este foro ahora que caigo.

Lo que probe hasta el momento me gusto, de todas maneras lo podrias
implementar vos esto con reflexion y ver estas cosas, porque aqui deberias
tomar alguna medida, cambia el assemblye entonces que hacemos? actualizo?
no? dejo la opcion al usuario. Pues... pero es un metodo piola porque
generas clientes inteligentes y potentes donde la administracion solo pasa
por ponerle un assembly a un servidor, es simple, a mi me gusta :-)


Salu2
Maxi

Hola Maxi,

"Maxi" escribió en el mensaje
news:

Hola Miguel

con respecto a la seguridad de window no es un unico usuario, sino el
usuario que inicia la aplicación, si hablamos de una aplicación en
windows, si hablamos de una aplicación Web cambia la cosa por que depende
de la configuración establecida.

A ver, si tengo 5 maquinas distintas, cuantas conexiones tendre?

Tienes 5 conexiones distintas, cada una con las credenciales del usuario que
ha iniciado sesión en esa maquina. Esto aplica a aplicaciones Windows, en
aplicaciones Web como te he comentado es igual si utilizas impersonalización
y seguridad integrada.

Con respecto al modelo de datos vuelves al caso de aplicaciones grandes,
de grandes organizaciones. Te recuerdo que estamos hablando de pequeñas
organizaciones que tienen que tener la mayor flexibilidad para
interactuar con otros componentes. Sin departamentos de DBA ni nada por
el estilo.

No te creas, hay organizaciones ´pymes q no tienen un dba pero necesitan
tener un control mejor de la base, o lo q es peor aun puede ser que hoy
sea una pequeña empresa y el dia de mañana tiene un dba o cosa simil, ahi
pues

Por regla general, si una empresa pyme tiene un desarrollo a medida cuando
crece demasiado ese desarrollo se queda completamente corto en todos los
niveles, y se pasa a otro proyecto o a un producto.

Cambiando de tema, ¿que experiencias has tenido con UpdaterBlock? de
mientras que llega OnceClick es lo que hay y no lo he probado aún, y
tengo un desarrollo que necesita algo similar. Aunque esta pregunta no es
de este foro ahora que caigo.

Lo que probe hasta el momento me gusto, de todas maneras lo podrias
implementar vos esto con reflexion y ver estas cosas, porque aqui deberias
tomar alguna medida, cambia el assemblye entonces que hacemos? actualizo?
no? dejo la opcion al usuario. Pues... pero es un metodo piola porque
generas clientes inteligentes y potentes donde la administracion solo pasa
por ponerle un assembly a un servidor, es simple, a mi me gusta :-)

Lo probaré pronto, me hace falta saber de que pie cojea.

Salu2
Maxi