sql para excluir algunos registros

[[BlueSteel]]

Hola

necesito realizar una sentencia sql en donde de los integrantes de una tabla me excluya los que estan en otra tabla...???

como se realiza esto ???

las tablas son:

Cliente
Cli_Rut
Cli_Nombres
Cli_Apellidos

Excluido
Cli_Rut



Salu2

[[enecumene]]

Código SQL [-]
SELECT * FROM TABLA WHERE CAMPO NOT EXISTS(QUERY)

Código SQL [-]
SELECT * FROM TABLA WHERE CAMPO NOT IN(QUERY)

Saludos.

[Neftali [Germán.Estévez]]

Revisa SELECT .. IN ... o SELECT... NOT IN ...

Código SQL [-]
  Select * from tabla1 where Campo1 NOT IN (select Campo2 from Tabla 2)

Se me adelantaton...
Hay que decir que debes taner algun campo común. En mi ejemplo, Campo1 y Campo2 deberían almacenar valores "concordantes"

[[BlueSteel]]

ok... muchas gracias...

me funcionó con esto

Código SQL [-]
SELECT * FROM Cliente WHERE Cli_Rut NOT IN(Select * From Excluidos)

intenté con el distinct, pero no me funcaba...

Salu2

[defcon1_es]

Hola, BlueSteel.
Prueba con la cláusula NOT EXISTS

Código SQL [-]
SELECT Cliente.*, Cli_Rut.*, Nombres.*, Apellidos.*
FROM Cliente
  INNER JOIN Cli_Rut
  ON (Cliente.[enlace_Cli_Rut]=Cli_Rut.[enlace_Cliente])
  INNER JOIN Nombres
  ON (Cliente.[enlace_Nombres]>=Nombres.[enlace_Cliente])
  INNER JOIN Apellidos
  ON (Cliente.[enlace_Apellidos]=Apellidos.[enlace_Cliente])
WHERE NOT EXISTS (SELECT Cli_Rut2.[ID_Cli_Rut]
                            FROM Cli_Rut Cli_Rut2
                            WHERE (Cli_Rut2.[ID_Cli_Rut] = Cli_Rut.[ID_Cli_Rut])
                            ORDER BY Cli_Rut2.[ID_Cli_Rut])

Con NOT IN, si la select principal devuelve muchos registros y la select secundaria tambien, puede tardar demasiado en mostrar la información, ya que por cada tupla de la select principal, se ejecuta la select secundaria...

[[Delphius]]

Hola a todos!

Amigo Blue, no pude evitar sentirme atraido por la problemática. Y esto se debe al diseño de dicha tabla.

No debería criticar tu diseño, no es mi intensión traerte problemas... pero me ha resultado un tanto extraño el diseño.

¿Tiene algún otro propósito y uso la tabla excluídos? ¿En ambas tablas Cli_RUT es la clave primaria?

Lo primero que se me pasó por la cabeza es que: un cliente puede ser excluído una sola vez, por tanto existirá cuanto mucho la misma cantidad de clientes en ambas tablas. Y esto conduce a una relación 1 a 1.

Al no conocer a detalles tu DER, no debería arriesgarme a decir algo. Pero mi naturaleza curiosa me lleva a esto.

Si dicha tabla no tiene otro fin más que de llevar un registro de excluído, lo que yo haría, de acuerdo a un primer análisis, es ponerla como un campo (booleano) más en la tabla cliente y la consulta queda simplemente:

Código SQL [-]
select tus_campos
from Clientes
where Excluido = 'NO'

Perdona que me haya metido en el tema.... es que me llama la curiosidad.

Saludos,

[[BlueSteel]]

Hola Delphius...

en realidad, en cuanto al diseño de las tablas tenia el campo de la tabla Excluidos como Exc_Rut, pero como no me funcionaba lo cambie por Cli_Rut... pense que era que el campo debia llamarse de la misma forma...(intente con el distinct , bueno.. un gran error)

En cuanto al diseño de las tablas, lo que pasa es que es para el mismo sorteo que estoy realizando (donde pregunte por el Random)... lo que pasa es que hoy me dicen que dentro de los clientes (o dueños de abonos) no pueden participar 2 personas, que son el Gerente del Club y el Presidente del Club y entre ellos son como 10 numeros...)

Con lo de poner alguna condición al campo para que este o no excluida, bueno, tambien es carta, es que no lo habia pensado (eso de estar pensando y trabajando en puro realizar conexiones de redes y wifi en la ultima semana me ha borrado la logica de programación)

Bueno... realizaré unas pruebas

Salu2

[roman]

En cuanto a lo que observa Delphius, si bien estoy de acuerdo con él, me gustaría comentar que en muchas ocasiones debemos manipular directamente las tablas y realizar consultas que muy posiblemente no haríamos dentro del sistema.

Por dar un ejemplo: tengo un tabla de solicitantes (a lo que sea) en la cual tengo -de hecho- el campo excluido. Por una u otra razón que va más allá del proceso normal del sistema, debo excluir varios de esos solicitantes. Posiblemente reciba la lista de éstos en un archivo de excel o de texto.

Lo que hago entonces, es importar la lista a una tabla temporal (la tabla excluidos) y hacer una actualización de la tabla de solicitantes:

Código SQL [-]
update solicitante
set excluido = 1
where clave in (select clave from excluido)

O sea, que aún contando con un campo propicio, he requerido de una tabla auxiliar y una consulta ad-hoc para la ocasión.

// Saludos

[[Delphius]]

Empezado por roman

En cuanto a lo que observa Delphius, si bien estoy de acuerdo con él, me gustaría comentar que en muchas ocasiones debemos manipular directamente las tablas y realizar consultas que muy posiblemente no haríamos dentro del sistema.

Por dar un ejemplo: tengo un tabla de solicitantes (a lo que sea) en la cual tengo -de hecho- el campo excluido. Por una u otra razón que va más allá del proceso normal del sistema, debo excluir varios de esos solicitantes. Posiblemente reciba la lista de éstos en un archivo de excel o de texto.

Lo que hago entonces, es importar la lista a una tabla temporal (la tabla excluidos) y hacer una actualización de la tabla de solicitantes:

Código SQL [-]update solicitante set excluido = 1 where clave in (select clave from excluido)


O sea, que aún contando con un campo propicio, he requerido de una tabla auxiliar y una consulta ad-hoc para la ocasión.

// Saludos

Hola Roman,
A ver si entiendo tu punto de vista... tal vez se deba a que mi cerebrito ya se está quedando sin baterias...

¿Entonces tu dices que en ciertas ocasiones es bueno o recomendable tener esas tablas para poder realizar operaciones, en forma externa al sistema, que no fueron contempladas en el desarollo del sistema? ¿A eso quieres llegar?

Perdona que te pregunte esa burrada, pero es que ando dormido.

Saludos,

[roman]

No es que sea ni bueno ni recomendable, pero muchas veces hay que hacer "talacha", cosas que, como dices, no están contempladas en el sistema y que muy posiblemente ni valga la pena considerar porque sólo se dan esporádicamente. O sea, que hay que meterse con el SQL a pelo, por fuera de todas nuestras consultas bien planeaditas del sistema.

// Saludos

[[Delphius]]

Empezado por roman

No es que sea ni bueno ni recomendable, pero muchas veces hay que hacer "talacha", cosas que, como dices, no están contempladas en el sistema y que muy posiblemente ni valga la pena considerar porque sólo se dan esporádicamente. O sea, que hay que meterse con el SQL a pelo, por fuera de todas nuestras consultas bien planeaditas del sistema.

// Saludos

Ahora entiendo.

¿Quién no tuvo que hacer alguna que otra "talacha" alguna vez? Si pudiera contarlas las que tuve que hacer yo...

Disculpa que te lo haya preguntado, y quitarte unos minutos... ando medio desenchufado y las ideas se me están durmiendo... creo que me hace falta una pequeña siesta y un poco de combustible al estómago.

Una pregunta más para el recuerdo:

Código Delphi [-]
inc(Delphius.Preguntas_tontas);

momento... no se puede usar inc para propiedades!

Código Delphi [-]
with Delphius do
  Preguntas_tontas := Preguntas_tontas + 1;

Saludos,