Personal Edition

Hola Maxi,

En el siguiente artículo se explica lo que comentas de la penalización a
partir de la novena petición:
http://msdn.microsoft.com/library/?...frame=true
Como dice en el artículo existen otras operaciones internas de MSDE que
tambien cuentan como operación, de ahí mi indicación de 5 usuarios
concurrentes, que es donde siempre había entendido que estaba la
limiticación. Con tu indicación y el artículo ya tengo por completo claras
las limitaciones de MSDE, que por otro lado no son muchas.

Con respecto a tu indicación de tener cuidado con este tipo de arquitectura,
esa arquitectura es la que actualmente se aplica en muchos proyectos, y
desde mi punto de vista simplifica el desarrollo y evita muchos de los
problemas que indicas:
- Con respecto a la seguridad, si cada cliente se conecta de forma directa
al servidor expones el servidor al resto de la red. En este caso si utilizas
autentificación SQL debes mantener la lista de usuarios y de inicios de
sesión en el mismo SQL, cosa que normalmente no hace nadie al ser mas
complejo de mantener que la típica tabla de usuarios mantenida por la misma
aplicación. Ademas los usuarios y las contraseñas son facilmente visibles
por la red con herramientas de snnifer si no proteges la red. Por otro lado
la autentificación Windows tambien es mas compleja de utilizar. La mejor
opción es utilizar la autentificación de Windows pero desde los componentes
situados en el servidor con una cuenta de usuario que tenga los permisos y
privilegios controlados.
- Con respecto a la injección de código ese es un problema de buenas
prácticas de desarrollo, que afecta a todo tipo de aplicaciones si el
programador no es cosciente del problema. Pero se soluciona con la
utilización de procedimientos almacenados, y sin utilizar setencias
dinámicas en estos procedimientos.
- La auditoría depende de como la implementes, pero no veo problema alguno.

Hoy en dia con las facilidades que ofrece .NET para la creación de
aplicaciones distribuidas es mucho mejor este tipo de aplicaciones que
aplicaciones más monoliticas, sobre todo con respecto a la escalabilidad.
Pero de todas forma es mi opinión.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Maxi" escribió en el mensaje
news:%

Hola miguel, ojo con lo que dices, no existe ningun limite de usuarios en
MSDE ni en la version personal. Lo que si existe es una penalizacion a la
novena peticion al servidor, pero podrias tener cientos de usuarios.

Ademas tambien ten mucho cuidado con esta tecnica de tener una sola
conexion para todo, ojo como manejas la seguridad, la injection de codigo,
las auditorias, etc.

Un abrazo


Salu2
Maxi


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

5 usuarios concurrentes, si diseñas tu aplicación con una arquitectura de
tres capas no vas a tener problemas.
Con este tipo de arquitectura son los componentes de la lógica de negocio
que están en el servidor los encargados de conectarse a la base de datos,
con eso reduces las necesidades de conexiones. Más de 5 usuarios deberían
solicitar a la vez algo al servidor para que la aplicación sobrepasara
este límite, te aseguro que en un entorno normal esto ocurre a partir de
un número bastante mayor de usuarios.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Yuri Aponte" escribió en el mensaje
news:u6CJXt%

50 usuarios conectados?Lei en la pagina de microsoft que solo era
para
cinco usuarios. y que de ahi en adelante se empezaba a degradar. Yo se
que
hay que diferenciar las especificaciones legales a los tecnicos. Pero
tampoco quiere decirle a mi cliente, "Instalemos nomas, que soporta un
monton y encima es gratis"...y luego tenga problemas legales e incluso
tecnicos por tener mas de cinco usuarios conectados...

Saludos

Yuri Aponte
Consultor de Sistemas
yuriPUNTOaponteARROBAspeedyPUNTOcomPUNTOpe

"Maxi" escribió en el mensaje
news:

Hola, yo lo tengo con un sistema que tiene 50 usuarios conectados


Maxi - Buenos Aires - Argentina
Desarrollador 3 Estrellas

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

"Yuri Aponte" escribió en el mensaje
news:
> No he escuchado buenas referencias del MSDE. has tenido experiencia
> con
> el?...lo has usado?funcionaran mis scripts de sql en
> el?...Disculpa
> las
> dudas, pero ya tengo mi base trabajada en SQL. y siempre me asusta
> hacer
> modificaciones estructurales sobre la marcha sin antes probarlas con
> tiempo.
>
> Saludos y gracias por la respuesta
>
> Yuri Aponte
> Consultor de Sistemas
> yuriPUNTOaponteARROBAspeedyPUNTOcomPUNTOpe
>
> "Gustavo Larriera [MVP]" escribió en el

mensaje

> news:
>> Si son tan pocos usuarios, usa MSDE 2000 que es gratuito.
>>
>> Gustavo Larriera
>> Uruguay LatAm
>> Blog: http://sqljunkies.com/weblog/gux/
>> MVP profile: http://aspnet2.com/mvp.ashx?GustavoLarriera
>> Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga

ningun

>> derecho / This posting is provided "AS IS" with no warranties, and
>> confers
>> no rights.
>> "Yuri Aponte" wrote in message
>> news:
>> > Hola amigos de la lista
>> >
>> > Tengo un cliente que tiene un SQL personal edition y me ha pedido
>> > una
>> > aplicacion pequeña para unos cuantos usuarios ( no creo que pasen
>> > de
> 5 ).
>> > Ahora el tema es: Se que legalmente el Personal Edition solo
>> > permite
>> > una
>> > conexion, bueno eso ya le dije a mi cliente, el tema es que si
>> > podra
>> > adquirir mas licencias?...Permite el PErsonal Edition el acceso de

mas

> de
>> > un
>> > usuario ?, solo es un aspecto legal o tambien tecnico?. Que puede

hacer

>> > este
>> > cliente, para poder montar su sistema en SQL teniendo tan pocos
>> > requerimientos de usuario.
>> >
>> > La decision tomada por el, es SQL de todas maneras, quiere
>> > seguridad
> ante
>> > todo, le conte del Access y casi me pega..ja,ja,ja..
>> >
>> > Saludos
>> >
>> >
>> > Yuri Aponte
>> > Consultor de Sistemas
>> > yuriuPUNTOaponteARROBAspeedyPUNTOcomPUNTOpe
>> >
>> >
>>
>>
>
>

Hola Miguel, entre lineas ;-)

Con respecto a tu indicación de tener cuidado con este tipo de
arquitectura, esa arquitectura es la que actualmente se aplica en muchos
proyectos, y desde mi punto de vista simplifica el desarrollo y evita
muchos de los problemas que indicas:

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 ;-)

- Con respecto a la seguridad, si cada cliente se conecta de forma directa
al servidor expones el servidor al resto de la red. En este caso si
utilizas autentificación SQL debes mantener la lista de usuarios y de
inicios de sesión en el mismo SQL, cosa que normalmente no hace nadie al
ser mas complejo de mantener que la típica tabla de usuarios mantenida por
la misma aplicación. Ademas los usuarios y las contraseñas son facilmente
visibles por la red con herramientas de snnifer si no proteges la red. Por
otro lado la autentificación Windows tambien es mas compleja de utilizar.
La mejor opción es utilizar la autentificación de Windows pero desde los
componentes situados en el servidor con una cuenta de usuario que tenga
los permisos y privilegios controlados.

mmm, esto no es del todo cierto, vos podrias tener encriptada la cadena de
conexion, no recomiendo como idea general q exista un solo usuario para todo
y que el control de haga via la aplicacion. El dia que tengan que hacer
auditorias o tunning de la base te vas a dar cuenta de lo que te menciono.
Muchos sistemas (y ERP famosos) usan un usuario de base por sesion y no
tienen estos problemas q vos mencionas. Hay muchas tras tecnicas para evitar
lo que indicas, por ej: Usar roles de aplicacion, usar Sp's, Etc, Ahora si
la cadena es visible, no usas Sp's y mandas todo sql desde la aplicacion,
entonces la cosa se complica mas. La macana de todo esto es la performance,
la seguridad, cuando quieran hacer un tunning, etc.

- La auditoría depende de como la implementes, pero no veo problema
alguno.

Aja, si tenes un solo usuario y yo quiero ver quien esta ejecutando un
proceso X que me esta haciendo colgar todo, como haces eso? Si quiero saber
la mac address de donde se conecta, si le quiero dar algunos permisos ? etc,
ni hablar si tenes q implementar un simple trigger de auditoria y que te
indique quien modifico el dato, de donde sacas el quien si siempre es el
mismo usuario? y si quieren implementar auditoria c2? ojo con esto!!!!

Hoy en dia con las facilidades que ofrece .NET para la creación de
aplicaciones distribuidas es mucho mejor este tipo de aplicaciones que
aplicaciones más monoliticas, sobre todo con respecto a la escalabilidad.
Pero de todas forma es mi opinión.

Este tema lo discuti el otro dia en una charla que di, y sabes cual fue la
conclusion de varios desarrolladores y DBA? que se habla mucho de la
escalabilidad pero se pierde de foco otra cosa, la performance, entonces vos
usas un com+ porque es escalable, pero la red puede llegar a morir porque
tenes un trafico impresionante. Creo que esto de ser extremistas y de poner
todo fuera de la base de datos no es uso del sentido comun, creo que se
deberia aprovechar de cada cosa lo mejor, y si para hacer un update lo pongo
en un com+ y asi hago con todo, voy a tener en teoria una alta escalabilidad
pero el sistema sera tan ineficiente que no podra ser tan real esa alta
escalabilidad.

Hace unos meses hice con un desarrollador un ejercicio de este tipo, un com+
atacando una base vs un Sp's haciendo lo mismo, los numeros fueron
increibles, el sp's 4 segundos el com+ 18 min, cuando duplicamos registros
el com+ 30' el sp' 5seg, en donde esta la escalabilidad?

Un abrazo!!!

Salu2
Maxi


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

Hola Maxi,

En el siguiente artículo se explica lo que comentas de la penalización a
partir de la novena petición:
http://msdn.microsoft.com/library/?...frame=true
Como dice en el artículo existen otras operaciones internas de MSDE que
tambien cuentan como operación, de ahí mi indicación de 5 usuarios
concurrentes, que es donde siempre había entendido que estaba la
limiticación. Con tu indicación y el artículo ya tengo por completo claras
las limitaciones de MSDE, que por otro lado no son muchas.

Con respecto a tu indicación de tener cuidado con este tipo de
arquitectura, esa arquitectura es la que actualmente se aplica en muchos
proyectos, y desde mi punto de vista simplifica el desarrollo y evita
muchos de los problemas que indicas:
- Con respecto a la seguridad, si cada cliente se conecta de forma directa
al servidor expones el servidor al resto de la red. En este caso si
utilizas autentificación SQL debes mantener la lista de usuarios y de
inicios de sesión en el mismo SQL, cosa que normalmente no hace nadie al
ser mas complejo de mantener que la típica tabla de usuarios mantenida por
la misma aplicación. Ademas los usuarios y las contraseñas son facilmente
visibles por la red con herramientas de snnifer si no proteges la red. Por
otro lado la autentificación Windows tambien es mas compleja de utilizar.
La mejor opción es utilizar la autentificación de Windows pero desde los
componentes situados en el servidor con una cuenta de usuario que tenga
los permisos y privilegios controlados.
- Con respecto a la injección de código ese es un problema de buenas
prácticas de desarrollo, que afecta a todo tipo de aplicaciones si el
programador no es cosciente del problema. Pero se soluciona con la
utilización de procedimientos almacenados, y sin utilizar setencias
dinámicas en estos procedimientos.
- La auditoría depende de como la implementes, pero no veo problema
alguno.

Hoy en dia con las facilidades que ofrece .NET para la creación de
aplicaciones distribuidas es mucho mejor este tipo de aplicaciones que
aplicaciones más monoliticas, sobre todo con respecto a la escalabilidad.
Pero de todas forma es mi opinión.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Maxi" escribió en el mensaje
news:%

Hola miguel, ojo con lo que dices, no existe ningun limite de usuarios en
MSDE ni en la version personal. Lo que si existe es una penalizacion a la
novena peticion al servidor, pero podrias tener cientos de usuarios.

Ademas tambien ten mucho cuidado con esta tecnica de tener una sola
conexion para todo, ojo como manejas la seguridad, la injection de
codigo, las auditorias, etc.

Un abrazo


Salu2
Maxi


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

5 usuarios concurrentes, si diseñas tu aplicación con una arquitectura de
tres capas no vas a tener problemas.
Con este tipo de arquitectura son los componentes de la lógica de
negocio que están en el servidor los encargados de conectarse a la base
de datos, con eso reduces las necesidades de conexiones. Más de 5
usuarios deberían solicitar a la vez algo al servidor para que la
aplicación sobrepasara este límite, te aseguro que en un entorno normal
esto ocurre a partir de un número bastante mayor de usuarios.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Yuri Aponte" escribió en el mensaje
news:u6CJXt%

50 usuarios conectados?Lei en la pagina de microsoft que solo era
para
cinco usuarios. y que de ahi en adelante se empezaba a degradar. Yo se
que
hay que diferenciar las especificaciones legales a los tecnicos. Pero
tampoco quiere decirle a mi cliente, "Instalemos nomas, que soporta un
monton y encima es gratis"...y luego tenga problemas legales e incluso
tecnicos por tener mas de cinco usuarios conectados...

Saludos

Yuri Aponte
Consultor de Sistemas
yuriPUNTOaponteARROBAspeedyPUNTOcomPUNTOpe

"Maxi" escribió en el mensaje
news:

Hola, yo lo tengo con un sistema que tiene 50 usuarios conectados


Maxi - Buenos Aires - Argentina
Desarrollador 3 Estrellas

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

"Yuri Aponte" escribió en el mensaje
news:
> No he escuchado buenas referencias del MSDE. has tenido experiencia
> con
> el?...lo has usado?funcionaran mis scripts de sql en
> el?...Disculpa
> las
> dudas, pero ya tengo mi base trabajada en SQL. y siempre me asusta
> hacer
> modificaciones estructurales sobre la marcha sin antes probarlas con
> tiempo.
>
> Saludos y gracias por la respuesta
>
> Yuri Aponte
> Consultor de Sistemas
> yuriPUNTOaponteARROBAspeedyPUNTOcomPUNTOpe
>
> "Gustavo Larriera [MVP]" escribió en el

mensaje

> news:
>> Si son tan pocos usuarios, usa MSDE 2000 que es gratuito.
>>
>> Gustavo Larriera
>> Uruguay LatAm
>> Blog: http://sqljunkies.com/weblog/gux/
>> MVP profile: http://aspnet2.com/mvp.ashx?GustavoLarriera
>> Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga

ningun

>> derecho / This posting is provided "AS IS" with no warranties, and
>> confers
>> no rights.
>> "Yuri Aponte" wrote in message
>> news:
>> > Hola amigos de la lista
>> >
>> > Tengo un cliente que tiene un SQL personal edition y me ha pedido
>> > una
>> > aplicacion pequeña para unos cuantos usuarios ( no creo que pasen
>> > de
> 5 ).
>> > Ahora el tema es: Se que legalmente el Personal Edition solo
>> > permite
>> > una
>> > conexion, bueno eso ya le dije a mi cliente, el tema es que si
>> > podra
>> > adquirir mas licencias?...Permite el PErsonal Edition el acceso
>> > de

mas

> de
>> > un
>> > usuario ?, solo es un aspecto legal o tambien tecnico?. Que puede

hacer

>> > este
>> > cliente, para poder montar su sistema en SQL teniendo tan pocos
>> > requerimientos de usuario.
>> >
>> > La decision tomada por el, es SQL de todas maneras, quiere
>> > seguridad
> ante
>> > todo, le conte del Access y casi me pega..ja,ja,ja..
>> >
>> > Saludos
>> >
>> >
>> > Yuri Aponte
>> > Consultor de Sistemas
>> > yuriuPUNTOaponteARROBAspeedyPUNTOcomPUNTOpe
>> >
>> >
>>
>>
>
>

Hola de nuevo,

aquí tienes una aplicación para poder gestionar el MSDE vía Web:
http://www.microsoft.com/downloads/...laylang=en

existen otras herramientas de terceros pero no he probado ninguna.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Pedro Pérez" escribió en el mensaje
news:

El MSDE es perfecto, solo lo que necesitaras un programa para poder
manejarlo con un entorno gráfico para que te seas más fácil administrarlo.

"Yuri Aponte" wrote in message
news:

Hola amigos de la lista

Tengo un cliente que tiene un SQL personal edition y me ha pedido una
aplicacion pequeña para unos cuantos usuarios ( no creo que pasen de 5 ).
Ahora el tema es: Se que legalmente el Personal Edition solo permite una
conexion, bueno eso ya le dije a mi cliente, el tema es que si podra
adquirir mas licencias?...Permite el PErsonal Edition el acceso de mas de

un

usuario ?, solo es un aspecto legal o tambien tecnico?. Que puede hacer

este

cliente, para poder montar su sistema en SQL teniendo tan pocos
requerimientos de usuario.

La decision tomada por el, es SQL de todas maneras, quiere seguridad ante
todo, le conte del Access y casi me pega..ja,ja,ja..

Saludos


Yuri Aponte
Consultor de Sistemas
yuriuPUNTOaponteARROBAspeedyPUNTOcomPUNTOpe

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.

Sigo entre líneas con tus comentarios:

"Maxi" escribió en el mensaje
news:%23k$

Hola Miguel, entre lineas ;-)

Con respecto a tu indicación de tener cuidado con este tipo de
arquitectura, esa arquitectura es la que actualmente se aplica en muchos
proyectos, y desde mi punto de vista simplifica el desarrollo y evita
muchos de los problemas que indicas:

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.

- Con respecto a la seguridad, si cada cliente se conecta de forma
directa al servidor expones el servidor al resto de la red. En este caso
si utilizas autentificación SQL debes mantener la lista de usuarios y de
inicios de sesión en el mismo SQL, cosa que normalmente no hace nadie al
ser mas complejo de mantener que la típica tabla de usuarios mantenida
por la misma aplicación. Ademas los usuarios y las contraseñas son
facilmente visibles por la red con herramientas de snnifer si no proteges
la red. Por otro lado la autentificación Windows tambien es mas compleja
de utilizar. La mejor opción es utilizar la autentificación de Windows
pero desde los componentes situados en el servidor con una cuenta de
usuario que tenga los permisos y privilegios controlados.

mmm, esto no es del todo cierto, vos podrias tener encriptada la cadena de
conexion, no recomiendo como idea general q exista un solo usuario para
todo y que el control de haga via la aplicacion. El dia que tengan que
hacer auditorias o tunning de la base te vas a dar cuenta de lo que te
menciono.
Muchos sistemas (y ERP famosos) usan un usuario de base por sesion y no
tienen estos problemas q vos mencionas. Hay muchas tras tecnicas para
evitar lo que indicas, por ej: Usar roles de aplicacion, usar Sp's, Etc,
Ahora si la cadena es visible, no usas Sp's y mandas todo sql desde la
aplicacion, entonces la cosa se complica mas. La macana de todo esto es la
performance, la seguridad, cuando quieran hacer un tunning, etc.

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.

- La auditoría depende de como la implementes, pero no veo problema
alguno.

Aja, si tenes un solo usuario y yo quiero ver quien esta ejecutando un
proceso X que me esta haciendo colgar todo, como haces eso? Si quiero
saber la mac address de donde se conecta, si le quiero dar algunos
permisos ? etc, ni hablar si tenes q implementar un simple trigger de
auditoria y que te indique quien modifico el dato, de donde sacas el quien
si siempre es el mismo usuario? y si quieren implementar auditoria c2? ojo
con esto!!!!

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.

Hoy en dia con las facilidades que ofrece .NET para la creación de
aplicaciones distribuidas es mucho mejor este tipo de aplicaciones que
aplicaciones más monoliticas, sobre todo con respecto a la escalabilidad.
Pero de todas forma es mi opinión.

Este tema lo discuti el otro dia en una charla que di, y sabes cual fue la
conclusion de varios desarrolladores y DBA? que se habla mucho de la
escalabilidad pero se pierde de foco otra cosa, la performance, entonces
vos usas un com+ porque es escalable, pero la red puede llegar a morir
porque tenes un trafico impresionante. Creo que esto de ser extremistas y
de poner todo fuera de la base de datos no es uso del sentido comun, creo
que se deberia aprovechar de cada cosa lo mejor, y si para hacer un update
lo pongo en un com+ y asi hago con todo, voy a tener en teoria una alta
escalabilidad pero el sistema sera tan ineficiente que no podra ser tan
real esa alta escalabilidad.

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.

Hace unos meses hice con un desarrollador un ejercicio de este tipo, un
com+ atacando una base vs un Sp's haciendo lo mismo, los numeros fueron
increibles, el sp's 4 segundos el com+ 18 min, cuando duplicamos registros
el com+ 30' el sp' 5seg, en donde esta la escalabilidad?

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.

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.

Un Saludo.

Un abrazo!!!

Salu2
Maxi


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

Hola Maxi,

En el siguiente artículo se explica lo que comentas de la penalización a
partir de la novena petición:
http://msdn.microsoft.com/library/?...frame=true
Como dice en el artículo existen otras operaciones internas de MSDE que
tambien cuentan como operación, de ahí mi indicación de 5 usuarios
concurrentes, que es donde siempre había entendido que estaba la
limiticación. Con tu indicación y el artículo ya tengo por completo
claras las limitaciones de MSDE, que por otro lado no son muchas.

Con respecto a tu indicación de tener cuidado con este tipo de
arquitectura, esa arquitectura es la que actualmente se aplica en muchos
proyectos, y desde mi punto de vista simplifica el desarrollo y evita
muchos de los problemas que indicas:
- Con respecto a la seguridad, si cada cliente se conecta de forma
directa al servidor expones el servidor al resto de la red. En este caso
si utilizas autentificación SQL debes mantener la lista de usuarios y de
inicios de sesión en el mismo SQL, cosa que normalmente no hace nadie al
ser mas complejo de mantener que la típica tabla de usuarios mantenida
por la misma aplicación. Ademas los usuarios y las contraseñas son
facilmente visibles por la red con herramientas de snnifer si no proteges
la red. Por otro lado la autentificación Windows tambien es mas compleja
de utilizar. La mejor opción es utilizar la autentificación de Windows
pero desde los componentes situados en el servidor con una cuenta de
usuario que tenga los permisos y privilegios controlados.
- Con respecto a la injección de código ese es un problema de buenas
prácticas de desarrollo, que afecta a todo tipo de aplicaciones si el
programador no es cosciente del problema. Pero se soluciona con la
utilización de procedimientos almacenados, y sin utilizar setencias
dinámicas en estos procedimientos.
- La auditoría depende de como la implementes, pero no veo problema
alguno.

Hoy en dia con las facilidades que ofrece .NET para la creación de
aplicaciones distribuidas es mucho mejor este tipo de aplicaciones que
aplicaciones más monoliticas, sobre todo con respecto a la escalabilidad.
Pero de todas forma es mi opinión.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Maxi" escribió en el mensaje
news:%

Hola miguel, ojo con lo que dices, no existe ningun limite de usuarios
en MSDE ni en la version personal. Lo que si existe es una penalizacion
a la novena peticion al servidor, pero podrias tener cientos de
usuarios.

Ademas tambien ten mucho cuidado con esta tecnica de tener una sola
conexion para todo, ojo como manejas la seguridad, la injection de
codigo, las auditorias, etc.

Un abrazo


Salu2
Maxi


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

5 usuarios concurrentes, si diseñas tu aplicación con una arquitectura
de tres capas no vas a tener problemas.
Con este tipo de arquitectura son los componentes de la lógica de
negocio que están en el servidor los encargados de conectarse a la base
de datos, con eso reduces las necesidades de conexiones. Más de 5
usuarios deberían solicitar a la vez algo al servidor para que la
aplicación sobrepasara este límite, te aseguro que en un entorno normal
esto ocurre a partir de un número bastante mayor de usuarios.

Un Saludo,

Miguel Angel Campos
MCAD.NET

"Yuri Aponte" escribió en el mensaje
news:u6CJXt%

50 usuarios conectados?Lei en la pagina de microsoft que solo era
para
cinco usuarios. y que de ahi en adelante se empezaba a degradar. Yo se
que
hay que diferenciar las especificaciones legales a los tecnicos. Pero
tampoco quiere decirle a mi cliente, "Instalemos nomas, que soporta un
monton y encima es gratis"...y luego tenga problemas legales e incluso
tecnicos por tener mas de cinco usuarios conectados...

Saludos

Yuri Aponte
Consultor de Sistemas
yuriPUNTOaponteARROBAspeedyPUNTOcomPUNTOpe

"Maxi" escribió en el mensaje
news:

Hola, yo lo tengo con un sistema que tiene 50 usuarios conectados


Maxi - Buenos Aires - Argentina
Desarrollador 3 Estrellas

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

"Yuri Aponte" escribió en el mensaje
news:
> No he escuchado buenas referencias del MSDE. has tenido experiencia
> con
> el?...lo has usado?funcionaran mis scripts de sql en
> el?...Disculpa
> las
> dudas, pero ya tengo mi base trabajada en SQL. y siempre me asusta
> hacer
> modificaciones estructurales sobre la marcha sin antes probarlas
> con
> tiempo.
>
> Saludos y gracias por la respuesta
>
> Yuri Aponte
> Consultor de Sistemas
> yuriPUNTOaponteARROBAspeedyPUNTOcomPUNTOpe
>
> "Gustavo Larriera [MVP]" escribió en el

mensaje

> news:
>> Si son tan pocos usuarios, usa MSDE 2000 que es gratuito.
>>
>> Gustavo Larriera
>> Uruguay LatAm
>> Blog: http://sqljunkies.com/weblog/gux/
>> MVP profile: http://aspnet2.com/mvp.ashx?GustavoLarriera
>> Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga

ningun

>> derecho / This posting is provided "AS IS" with no warranties, and
>> confers
>> no rights.
>> "Yuri Aponte" wrote in message
>> news:
>> > Hola amigos de la lista
>> >
>> > Tengo un cliente que tiene un SQL personal edition y me ha
>> > pedido una
>> > aplicacion pequeña para unos cuantos usuarios ( no creo que
>> > pasen de
> 5 ).
>> > Ahora el tema es: Se que legalmente el Personal Edition solo
>> > permite
>> > una
>> > conexion, bueno eso ya le dije a mi cliente, el tema es que si
>> > podra
>> > adquirir mas licencias?...Permite el PErsonal Edition el acceso
>> > de

mas

> de
>> > un
>> > usuario ?, solo es un aspecto legal o tambien tecnico?. Que
>> > puede

hacer

>> > este
>> > cliente, para poder montar su sistema en SQL teniendo tan pocos
>> > requerimientos de usuario.
>> >
>> > La decision tomada por el, es SQL de todas maneras, quiere
>> > seguridad
> ante
>> > todo, le conte del Access y casi me pega..ja,ja,ja..
>> >
>> > Saludos
>> >
>> >
>> > Yuri Aponte
>> > Consultor de Sistemas
>> > yuriuPUNTOaponteARROBAspeedyPUNTOcomPUNTOpe
>> >
>> >
>>
>>
>
>

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