necesito un experto en TSQL

Hola, Gabriel:

T-SQL no es "SQL Estandar": es T-SQL. De todas maneras, todos los motores de
BBDD soportan las operaciones JOIN (de hecho estan definidas en los
estandares ISO SQL, aunque Oracle parece emplear una sintaxis un poco suya).
De manera que un LEFT JOIN deberia resolverte el problema.

Mi problema con los LEFT JOIN no es lo de la estandarizacion, mas bien que
soy bastante bruto. Hasta ahora he tenido suerte manejando los JOIN
complejos como consultas de UNION:

La consulta decente deberia ser algo como:

SELECT Apellidos.Apellido, Nombres.Nombre
FROM Apellidos LEFT JOIN Nombres
ON Apellidos.idPuesto = Nombres.idPuesto

y se puede reescribir asi:

SELECT Apellidos.Apellido, Nombres.Nombre
FROM Apellidos, Nombres
WHERE Apellidos.idPuesto = Nombres.idPuesto
UNION
SELECT Apellidos.Apellido, '' FROM Apellidos
WHERE NOT idPuesto IN
(SELECT idPuesto
FROM Nombres)

aunque lo mas probable es que si tienes que lidiar con un SGBD que no
entienda el LEFT JOIN, eventualmente darás con otro que no entienda el
UNION.


Salud!



"Gabriel Pravaz" escribió en el mensaje
news:OZ5Mm%

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.

jaja, bueno que no entienda el union ya...Quiero puntualizar algo
importabnte, 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, pero hoy dia un proyecto nuevo no se deberia hacer en otra bdd
que no sea SQLServer (costos/beneficio) a menos que el cliente ya disponga
de su motor.

Si quieren algo bien pero bien ANSI (ojo que en SQL2005 noo funcionaaa) es
esto

Select campos from tabla1,tabla2
where tabla1.id *= tabla2.id (equivale a un Left join)

Bye


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:%

Hola, Gabriel:

T-SQL no es "SQL Estandar": es T-SQL. De todas maneras, todos los motores
de BBDD soportan las operaciones JOIN (de hecho estan definidas en los
estandares ISO SQL, aunque Oracle parece emplear una sintaxis un poco
suya). De manera que un LEFT JOIN deberia resolverte el problema.

Mi problema con los LEFT JOIN no es lo de la estandarizacion, mas bien que
soy bastante bruto. Hasta ahora he tenido suerte manejando los JOIN
complejos como consultas de UNION:

La consulta decente deberia ser algo como:

SELECT Apellidos.Apellido, Nombres.Nombre
FROM Apellidos LEFT JOIN Nombres
ON Apellidos.idPuesto = Nombres.idPuesto

y se puede reescribir asi:

SELECT Apellidos.Apellido, Nombres.Nombre
FROM Apellidos, Nombres
WHERE Apellidos.idPuesto = Nombres.idPuesto
UNION
SELECT Apellidos.Apellido, '' FROM Apellidos
WHERE NOT idPuesto IN
(SELECT idPuesto
FROM Nombres)

aunque lo mas probable es que si tienes que lidiar con un SGBD que no
entienda el LEFT JOIN, eventualmente darás con otro que no entienda el
UNION.


Salud!



"Gabriel Pravaz" escribió en el mensaje
news:OZ5Mm%

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.

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

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

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