ayuda con consulta

[mackbeth]

Hola a todos, tengo una gran duda al realizar una consulta, ya busque varias maneras, y me decidi a consultar en mi foro favorito, estoy trabajando en sql server 2005 express y tengo las siguientes tablas:

1.- Administrativo con los campos: ad_contrato,ad_mac, ad_velocidad, ad_estado, ad_lugar (con 3500 registros)
2.- Tecnico con los campos: tec_mac, tec_velocidad, tec_estado (con 3600 registros)

el objetivo de esta pekeña bd es buscar inconsistencias entre ambas tablas,
en ellas, los campos en comun son ad_mac y tec_mac,el problema es que necesito saber que registros en tecnico son los que no aparecen en administrativo, sinceramente no me doy idea de como hacer esa consulta, alguien podria ayudarme???

[daniel00]

Que tal Mackbeth.

Código:

SELECT t.* 
FROM Tecnico t right outer join Administrativo a ON
    t.tec_mac = a.ad_mac
WHERE  a.ad_mac IS NULL

Saludos!

[mackbeth]

Muchas gracias por responder rapido Daniel00, he probado tu sentencia, pero ne devuelve puros valores nulos

[iislas]

Hola Mackbeth

Dime si funciona esta sentencia.

SELECT * FROM Tecnico WHERE tec_mac NOT IN(SELECT DISTINCT ad_mac FROM Administrativo)

[mackbeth]

Me parece excelente tu consulta y muy logica, pero desafortunadamente no funciono me devolvio 0 registros

[iislas]

Entonces, quiere decir que TODOS los registros de TECNICO estan en ADMINISTRATIVO, asi de simple.

[mackbeth]

Pues no lo creo, por que en tecnico hay 100 registros mas que en administrativo,como lo puse en el primer post, administrativo tiene 3500 y tecnico 3600, de hecho estoy pensando en meter la consulta en una aplicacion .net y con ayuda de un datareader, hacer una busqueda por codigo, aunque inicialmente no queria hacer la aplicacion, pero al no haber de otra, publicare el codigo de la aplicacion

[iislas]

No, espera, ¿eso quiere decir que entonces NO TIENES una Primary Key?

Porque en el ejemplo que te puse, hace referencia al PK (tec_mac, ad_mac), o dime, ¿Que campos conforman tu PK?

[mackbeth]

asi es, como no puede existir una mac duplicada ni en administrativo ni tecnico, decidi ponerlo como pk

[iislas]

Aclarame algo, los 3500 registros en TECNICO, son UNICOS????

[mackbeth]

asi es, no puede existir mac duplicadas, por eso los puse como pk, donde no se pueden repetir registros ni quedar nulos

[iislas]

Pues si son UNICOS, la consulta:

SELECT * FROM Tecnico WHERE tec_mac NOT IN(SELECT DISTINCT ad_mac FROM Administrativo)

Debe darte aquellos registros que estan en TECNICO y NO SE ENCUENTRAN en ADMINISTRATIVO.

Eso que ni que.................

[Andres95]

Retomando la sentencia de Daniel...
Solo hay que cambiar el join derecho por uno izquierdo...
Para tablas con muchos registros, es mejor hacer un join...

Saludos!

Código:

SELECT t.* 
FROM    Tecnico t 
Left outer join 
          Administrativo a 
ON    t.tec_mac = a.ad_mac
WHERE  a.ad_mac IS NULL

[Gabo77]

MackBeth, esta consulta es la que te devuelve el resultado..... Saludos!

Código:

Select *
From Tecnico T
WHERE Not Exists(
    Select 1
    From Administrativo A
    WHERE A.Ad_Mac = T.Ad_Mac
)

[Mithrandir]

Estaba por contestar lo mismo que ya Andrés ha corregido. Esa manera funcionará de acuerdo a lo esperado.

Personalmente, procuro alejarme de los subquerys cuando trato con tablas con muchos registros.

[Gabo77]

Jeje, yo tengo muy buenas experiencias de los cursores frente a los Joins, he logrado mejorar le rendimiento de las bd's de donde trabajo sacando joins y usando la sentencia exists...


Saludos!

[Mithrandir]

He escuchado que bajo ciertas circunstancias, el subquery es más eficiente que el join, por ejemplo en el caso de que las tablas no tengan índices.

Aunque no creería que ese sea tu caso. Por mera curiosidad... ¿Cual es tu caso? ¿Tablas grandes? ¿Indices? ¿hints activados?

[mackbeth]

MUCHAS GRACIAS A TODOS POR SU AYUDA, ESPECIALMENTE A GABO QUE SU CONSULTA ME DIO EL RESULTADO QUE ESPERABA, YA QUE MI VALIDACION Y SU CONSULTA ME DEVOLVIERON EXACTAMENTE EL MISMO RESULTADO, DE TODAS MANERAS COMO HABIA COMENTADO, LO HICE CON CODIGO VB Y AQUI ESTA:

Dim administrativo(0), tecnico(0) As String
Dim dr As SqlDataReader
Dim a As Integer = 0
'================================================= =====
'inicio de busqueda de inconsistencias de alta en administrativo y no en tecnico
Public Sub inc_administrativo_tecnico()
'inicializacion de variables y arreglos
a = 0
ReDim inc(1)
ReDim tecnico(1)
ReDim administrativo(1)
'llenado de arreglo con mac address de tecnico
dr = obj.QueryDR("select tecnico_mac from tecnico")
While dr.Read
tecnico(a) = dr.Item("tecnico_mac").ToString
a += 1
ReDim Preserve tecnico(a)
End While
'vaciado de variables
dr = Nothing
a = 0
'llenado de arreglo con mac adress de administrativo
dr = obj.QueryDR("select administrativo_mac from administrativo")
While dr.Read
administrativo(a) = dr.Item("administrativo_mac").ToString
a += 1
ReDim Preserve administrativo(a)
End While
'inicio de la validacion
For i = 0 To tecnico.Length - 1
For j = 0 To administrativo.Length - 1
If administrativo(j) = tecnico(i) Then
administrativo(j) = 0
End If
Next
Next
For i = 0 To administrativo.Length - 1
If CType(administrativo(i), Object) <> "0" Then
ReDim Preserve inc(i)
inc(i) = CType(administrativo(i), Object)
End If
Next
End Sub


Muchas Gracias a Todos!!

[Gabo77]

Iniciado por Mithrandir

He escuchado que bajo ciertas circunstancias, el subquery es más eficiente que el join, por ejemplo en el caso de que las tablas no tengan índices.

Aunque no creería que ese sea tu caso. Por mera curiosidad... ¿Cual es tu caso? ¿Tablas grandes? ¿Indices? ¿hints activados?

Una tabla de Log de eventos, contiene mas de 25 millones de registros, la tabla está indexada por un campo llamado idenvio (no es llave por que al ser log registra muchos eventos para el mismo idenvio con diferencia del mensaje arrojado por el sistema y la fecha) cuando busco un idenvio especifico que se encuentra en otra tabla si lo hago vía JOINS (mediante el campo IdEnvio que en la otra tabla si es llave) me tarda entre 20 y 30 segundos , haciendolo en un EXISTS(SubConsulta) Me tarda entre 2 y 3 segundos.... :D Amo mi Exists!

Saludos!