necesito un experto en TSQL

En este sentido,
una aplicacion capaz de trabajar en el nuevo ambiente de la misma
manera que trabajaba en el anterior es mejor que una que simplemente
debe descartarse.

Seguro, pero en mi opinion el ANSI SQL no es la mejor solucion. Seguro no
habria problemas con consultas simples pero cuando necesitas hacer cosas
algo mas complejas el estandar queda corto y terminarias procesando la data
en la aplicacion cuando el servidor (usando el SQL correspondiente) podria
hacerlo mucho mas facil y mejor.

El que una aplicación diseñada como un producto barato (que no
necesariamente debe ser malo: simplemente es barato) pueda soportar
varias plataformas es una cosa buena, y su calidad es mejor que si se
limitara a la BD "low end" del diseño inicial.

Aqui me perdi :( Yo no dije en ningun momento que barato = malo. Si es sobre
mi comentario sobre el SGBD caro, mi intencion iba por el lado de lo que
escribiste: "Es decir, si tienes un servidor SQL Server y lo tratas como si
fuera el motor Jet, tu aplicación es pésima."

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C

Hola amigo!! es la discusion de nunca acabar!! :-), hoy lo que digo que con
SQL 2005 y con el poder que ya tiene quedan cada vez mas chico el resto, o
sea: Si tenes una bdd mayor a 4gb en data recien ahi podrias pensar en otro
motor, pero nadie tiene la verdad!! lo que digo que cada dia SQL y Oracle
son Standares y con sus versiones Free estan llevando a casi todo mundo a
usarlos, te cuento mas: hemos comprado hace poco un equipo que hace
espectrofotrometria y viene con una PC de escritorio con un sistema, a que
no sabes que bdd usan? ;-)


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Leonardo Azpurua [mvp vb]" <l e o n a r d o (arroba) m v p s (punto) o r g>
escribió en el mensaje news:

"Maxi" escribió en el mensaje
news:

Eso es cierto, por eso yo siempre tengo esta idea: Las empresas por lo
general tienen su motor, o es SQL o es Oracle, el mercado esta ahi, y
luego hay un mercado mucho mas chico para el resto. Las aplicaciones si
las pensamos para una tecnologia no esta nada mal, si es una aplicacion
super importante podre hacerla funcionar en 2, pero no veo con buenos
ojos a aquellas aplicaciones que quieren funcionar con todo tipo de
motor, porque digo esto? porque para hacerlo asi realmente se deberia
hacer una capa para cada tipo de motor y siempre usar el poder de cada
uno

Hola, Maxi:

Esta es la discusion de nunca acabar.

En primer lugar no es cierto que el mercado para el resto sea "mucho mas
chico".

Por cada empresa que puede comprar SQL Server u Oracle, hay al menos
veinte que no pueden incurrir en ese gasto (ademas de que no lo
necesitan).

Tambien es cierto que las empresas que pueden y necesitan comprar SQL
Server u Oracle estan dispuestas a pagar por sus aplicaciones veinte o mas
veces que las que no pueden comprarlo. Por otra parte, la competencia en
ese sector es mucho mas fuerte (y mucho mas calificada - casi siempre) que
la que te encuentras cuando trabajas para clientes mas pequeños.

Además, hay otro nivel de aplicaciones -muy "high end"- donde la simple
sobrecarga de traducir de SQL a mecanismos de búsqueda degrada el
rendimiento a niveles inaceptables (ese es el exito de DB2 en aplicaciones
OLTP de grandes volúmenes, como la gestion bancaria, por ejemplo).

Me gustan las innovaciones, pero no encuentro para nada sensata la actitud
de valorar la calidad de las aplicaciones por la novedad de las
tecnologías que emplean. Ya no lo hago, por cuestiones de comodidad (hay
una edad en la que te conformas con que las cosas funcionen, y las
aplicaciones de acceso a datos se han vuelto tan, pero tan ineficientes
con el paso de los años, que nadie nota mi pereza) pero alguna vez tuve
que comparar el rendimiento entre acceder a una pequeña tabla usando
Pervasive SQL (concedido que es una babosa en cuanto al rendimiento),
accesos al microkernel de Btrieve o simplemente guardando los datos en un
archivo con un array de imagenes binarias de los registros (es decir, un
archivo plano), y la mejor opcion, por factores de 10 a 1 (comparada con
el uso del microkernel) o de 300 a 1 (comparada con el acceso a traves de
Pervasive SQL) era el archivo plano.

El diseño de aplicaciones es en gran medida el arte del compromiso: en
algun momento tienes que decidir entre aprovechar todos los pitos y
tambores de un nuevo producto o la accesibilidad de uno mas viejo y no tan
publicitado. Cada vez que tomas una opción, estás renunciando a los
beneficios de las que descartaste. Y las fuerzas objetivas que llevan a un
desarrollador a tomar la decisión correcta pueden ser diferentes de las
fuerzas objetivas que llevan a otro desarrollador a tomar la decisión
contraria, de manera igualmente correcta.

Por otra parte, puedes utilizar clases adaptadoras, capaces de generar
sentencias SQL correctas, o de utilizar recursos especificos del proveedor
de acceso a BD, dentro del mismo nivel de aplicacion, con una sobrecarga
de una o dos llamadas a funciones dentro del mismo espacio de
aplicacion -o dentro del mismo proceso- para controlar una conexión que
tambien esta denro del mismo espacio de aplicacion. De esta manera puedes
generar codigo adaptable a diferentes proveedores sin necesidad de
utilizar capas reemplazables (no es que sea la mejor solucion, pero con
mucha frecuencia es la mas simple, y volvemos a la historia de las
decisiones y los compromisos).


Salud!

Hola,

Mi punto de discusión es que el simple hecho de desperdiciar recursos del
SGBD no es suficiente para descalificar una aplicacion.

Nooo, creo que se mal interpreto, yo no descalifico a las aplicaciones, no
hay recetas en esto, cada aplicacion es un mundo distinto. Lo que digo es
que pensemos y pensemos y no seamos automatas, como dice el cuentito:

Mama porque haces el pescado en 2 fuentes
Pues porque mi mama (tu abuela lo hacia asi).
aja, abuela porque hacias el pescado en 2 fuentes, ahhh porque mi mama (o
sea tu bisabuela) lo havia asi
Bisabuelita porque haces el pescado en 2 fuentes!! ahhh querido eso lo hacia
porque en esos tiempos las fuentes eran mas chicas y no entraba en una sola.

Me refiero a esto!! hace años q nos vienen diciendo capa de acceso a datos
porque seguro que debo tener muchas bdd, bien eso es cierto, pero ojo, lo
simple hay veces que puede ser peligroso y no se puede aplicar a cualquier
cosa, hay que saber interpretar donde y cuando aplicarlo, si yo tengo q hace
una aplicacion de mision critica voy a poner todo la fuerza en usar al
maximo todo lo q me da la tecnologia, ahora si hago una aplicacion de 5
usuarios mas chica deberia pensarlo.

Un abrazo


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Leonardo Azpurua [mvp vb]" <l e o n a r d o (arroba) m v p s (punto) o r g>
escribió en el mensaje news:

"Antonio Ortiz" escribió en el mensaje
news:

mmm, y que paso con aquello de Acceso Universal a Datos?.

Tengo aplicaciones sobre BD Jet (Access) que se conecta a BD SQL Server
sin problemas, mientras mantenga la misma estructura. Claro que como
indicas el problema viene al utilizar SQL del lado del cliente, por los
distintos 'dialectos'

Hola, Antonio:

En T-SQL tienes una cantidad de recursos que no existen en Access:
triggers, procedimientos almacenados mucho mas complejos que las simples
consultas de Access, vistas inexadas y la capacidad de simplificar el
calculo del plan de ejecuión, mediante la clasula HINT, que te permite
optimizar con gran detalle los metodos de acceso a datos de tu aplicacion.

Creo que a lo que se refería Maxi, y lleva razon en ello, es que una
aplicacion que trabaje con diferentes gestores de BBDD no aprovecha las
capacidades especificas de ninguno y en consecuencia siempre implica un
poco de desperdicio.

Mi punto de discusión es que el simple hecho de desperdiciar recursos del
SGBD no es suficiente para descalificar una aplicacion.

Salud!

Hola, bueno aca no coincidimos!! decime cual es la diferencia entre usar un
MDB y SQL Express? cual es la ventaja que le ves? yo no le veo ninguna por
eso te pregunto


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Leonardo Azpurua [mvp vb]" <l e o n a r d o (arroba) m v p s (punto) o r g>
escribió en el mensaje news:

"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:%

Creo que a lo que se refería Maxi, y lleva razon en ello, es que una
aplicacion que trabaje con diferentes gestores de BBDD no aprovecha
las capacidades especificas de ninguno y en consecuencia siempre
implica un poco de desperdicio.
Mi punto de discusión es que el simple hecho de desperdiciar recursos
del SGBD no es suficiente para descalificar una aplicacion

En realidad lo empece yo no Maxi. Lo que queria decir es que se pierde
mucho usando SQL estandar, y terminas haciendo en codigo muchas cosas que
podrias haberle dejado al SGBD con lo cual pierdes rendimiento y eso baja
la calidad de cualquier aplicacion (y peor si se esta usando un SGBD
caro).

Hola.

Creo que la esencia de la ingeniería desde sus comienzos ha sido minimizar
los recursos requeridos para obtener el resultado deseado.

Esa misma definición vista desde otro angulo, puede replantearse como
obtener los mejores resultados posibles con los recursos disponibles.

Es decir, si tienes un servidor SQL Server y lo tratas como si fuera el
motor Jet, tu aplicación es pésima.

De la misma manera en que es pésima la decisión de comprar SQL Server
cuando lo que tienes que hacer lo puedes hacer con Access de manera
satisfactoria.

Hay casos, sin embargo, en los que un archivo .MDB alojado en un pequeño
servidor se queda corto para atender un numero creciente de equipos, o un
aumento importante en el volumen de transacciones. En ese momento el
cliente debe aumentar la capacidades del servidor. Pero en el caso de
Access, no basta con cambiar un servidor por un equipo mas poderoso: es
necesario migrar a un nuevo servidor de BBDD. Si la aplicacion original no
soporta el uso de otros servidores, se debe descartar tambien la
aplicacion, con un costo mayor para el usuario final, que debe adquirir
una nueva aplicacion, migrar los datos y adaptar sus procedimientos a la
"manera de hacer" de la nueva aplicacion (y un cliente menos para la
aplicacion). En este sentido, una aplicacion capaz de trabajar en el nuevo
ambiente de la misma manera que trabajaba en el anterior es mejor que una
que simplemente debe descartarse.

Es decir, en determinados escenarios, muy frecuentes en el segmento de las
pequeñas y medianas empresas, el que la aplicación pueda "escalar" al paso
de los requerimientos es mucho mas una ventaja que una deficiencia. Es
cierto que la aplicacion desperdicia recursos, pero tambien es cierto que
produce los resultados deseados con tiempos de respuesta aceptables.

Entonces mi desacuerdo es con lo "absoluto" de tu calificación. El que una
aplicación diseñada como un producto barato (que no necesariamente debe
ser malo: simplemente es barato) pueda soportar varias plataformas es una
cosa buena, y su calidad es mejor que si se limitara a la BD "low end" del
diseño inicial.


Salud!

"Maxi" escribió en el mensaje
news:

Hola, bueno aca no coincidimos!! decime cual es la diferencia entre usar
un MDB y SQL Express? cual es la ventaja que le ves? yo no le veo ninguna
por eso te pregunto

Hola...

Digamos que la aplicacion tiene siete años, y se concibió inicialmente para
trabajar con archivos de Access :-)))