Forums Últimos mensajes - Powered by IBM
 
Tags Palabras claves

necesito un experto en TSQL

09/06/2006 - 04:51 por Gabriel Pravaz | Informe spam
Ayuda Hacer una pregunta
que me ayude a resolver el sig problema:

tengo dos tablas que se parecen a esto (trato de simplificarlo)

Apellidos

idPuesto
Apellido
-

Nombres

idPuesto
Nombre

puede haber uno o ningun registro de la tabla nombres por cada registro de
la tabla apellidos, nunca hay dos o mas.

y quiero hacer una consulta que me devuelva nombres y apellidos segun el
Puesto de trabajo en SQL Estándar (sin utilizar inner joins ni cosas que no
acepten todos los motores de bbdd)

seria algo asi:

SELECT Apellidos.Apellido, Nombres.Nombre
FROM Apellidos, Nombres
WHERE idPuesto = 'argumento' AND Apellidos.idPuesto = Nombres.idPuesto;

EL PROBLEMA es que hay registros de la primer tabla que no tienen
coincidente en la segunda tabla, deben aparecer en la consulta pero esta no
los trae ya que se filtran en el momento en que igualo el campo idPuesto
para hacer el equivalente al Inner Join.

Si la solución es que modifique la estructura de la base de datos, me
encantaría pero ya está hecha así y no se puede tocar. Yo no soy partidario
de hacer varias tablas que tengan relacion 1 a 1, prefiero hacer tablas mas
anchas, pero este caso ya vino así.

Si se tomaron el trabajo de leerlo muchas gracias.
email Siga el debateRespuesta 16 respuestasRespuesta Tengo una respuesta

Preguntas similare

Mostrar todos los temas similares

Leer las respuestas

#6 Antonio Ortiz
11/06/2006 - 00:11 | Informe spam
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'


saludos,

Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com



"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, esto
obliga a no usar SQL desde la aplicacion, entonces si queremos realmente
que funcione en Oracle & SQL por ej deberiamos tener un esquema asi:

UI - BL - DAL - BDD

DAL llama siempre a Stores de BDD con lo cual deberia tener tantos modelos
de Stores como modelos de BDD, en cada Store usar el lenguaje de ese
motor, por ej TSQL o PLSQL y asi obtener los mayores beneficios.
Quien hace realmente esto? por lo general lo que hacen es poner las
sentencias fuera y con eso se olvidan de que funcione en cada motor, bueno
esto trae unos problemas terribles en otros puntos mas, habra aplicaciones
donde se pueda hacer habra otras que ni de casualidad se pueda hacer, hay
que estudiarlo.


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


"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:
El join es ANSI lo que sucede es que no todas las bdd lo
soportan, va si hablamos en serio te diria que no lo soporta ni
access ni mysql creo,



Mmmm... Access si soporta el JOIN. Pero por mas ANSI que ande dando
vueltas por ahi, es imposible crear una buena aplicacion usando solo ANSI
SQL.

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





Respuesta Responder a este mensaje
#7 Leonardo Azpurua [mvp vb]
11/06/2006 - 08:57 | Informe spam
"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!
Respuesta Responder a este mensaje
#8 Eduardo A. Morcillo [MS MVP VB]
12/06/2006 - 01:47 | Informe spam
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).

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C
Respuesta Responder a este mensaje
#9 Leonardo Azpurua [mvp vb]
12/06/2006 - 03:44 | Informe spam
"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!
Respuesta Responder a este mensaje
#10 Antonio Ortiz
12/06/2006 - 06:24 | Informe spam
asi lo comprendi; por supuesto que no son comparables, solo comentaba la
funcionalidad de la aplicacion. Pues un MDB para nada es un
cliente-servidor.

;)

saludos,

Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com




"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!


Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida