2009-04-20 4 views

Respuesta

21
SELECT * FROM some_table WHERE ID IN ('1001', '1002', '1003') 

y si sus identificadores conocidos son procedentes de otra tabla

SELECT * FROM some_table WHERE ID IN (
    SELECT KnownID FROM some_other_table WHERE someCondition 
) 
0

Para un conjunto fijo de identificadores que puede hacer:

SELECT * FROM some_table WHERE id IN (1001, 2002, 3003); 

Para un conjunto que cambia cada vez, es posible que desee crear una tabla para mantenerlos y luego consultar:

SELECT * FROM some_table WHERE id IN 
    (SELECT id FROM selected_ids WHERE key=123); 

Otro enfoque es usar colecciones, la sintaxis para esto dependerá de su DBMS.

Por último, siempre existe este enfoque "kludgy":

SELECT * FROM some_table WHERE '|1001|2002|3003|' LIKE '%|' || id || '|%'; 
+2

ALÉJATE de la opción LIKE. Las conversiones de cadenas son lentas, las comparaciones de cadenas son lentas, y LIKE '% ...%' significa que los índices no se pueden usar. No puedo exagerar cuánto se debe evitar esta opción (imo). – MatBailie

7

La primera opción (ingenua):

SELECT * FROM some_table WHERE id IN ('1001', '2002', '3003' ...) 

Sin embargo, debemos ser capaces de hacerlo mejor. IN es muy malo cuando tienes muchos elementos, y mencionaste cientos de estos ids. ¿Qué los crea? ¿De dónde vienen? ¿Puedes escribir una consulta que devuelva esta lista? Si es así:

SELECT * 
FROM some_table 
INNER JOIN (your query here) filter ON some_table.id=filter.id 
2

Las OR son notoriamente lentas en SQL.

Su pregunta es corto en detalles, pero dependiendo de sus necesidades y limitaciones que sería construir una tabla de consulta con sus identificaciones y utilizar el predicado EXISTS:

select t.id from some_table t 
where EXISTS (select * from lookup_table l where t.id = l.id) 
0

En Oracle, siempre pongo el id 's en un TEMPORARY TABLE para llevar a cabo masiva SELECT' s y DML operaciones:

CREATE GLOBAL TEMPORARY TABLE t_temp (id INT) 


SELECT * 
FROM mytable 
WHERE mytable.id IN 
     (
     SELECT id 
     FROM t_temp 
     ) 

Usted puede llenar la tabla temporal en una sola ida y vuelta cliente-servidor utilizando Oracle tipos de colección.

+0

¿Puede alguien decirme si las tablas temporales son buenas o malas? –

+0

Para una tarea como esta, sin duda son buenas. – Quassnoi

+0

En primer lugar, no producen REDO ni DESHACER, lo que significa que son unas 20 veces más rápidas que las permanentes. – Quassnoi

0

Tenemos un problema similar en una aplicación escrita para MS SQL Server 7. Aunque me gusta la solución utilizada, no somos conscientes de algo mejor ...

existen soluciones 'mejor' en 2008 en la medida de como sé, pero tenemos clientes Cero usando eso :)


Creamos una función definida por el usuario con una tabla que toma una cadena de ID delimitada por comas, y devuelve una tabla de ID. El SQL entonces lee razonablemente bien, y ninguno de ellos es dinámico, pero aún existe la molesta sobrecarga doble:
1.Cliente concatena los identificadores en la cadena
2. SQL Server analiza la cadena para crear una tabla de identificadores de

Hay muchas formas de convertir '1,2,3,4,5' en una tabla de identificadores, pero el procedimiento almacenado que utiliza la función termina pareciéndose ...

CREATE PROCEDURE my_road_to_hell @IDs AS VARCHAR(8000) 
AS 
BEGIN 

    SELECT 
     * 
    FROM 
     myTable 
    INNER JOIN 
     dbo.fn_split_list(@IDs) AS [IDs] 
     ON [IDs].id = myTable.id 

END 
0

el más rápido es poner los identificadores de otra tabla y unirse a

SELECT some_table.* 
FROM some_table INNER JOIN some_other_table ON some_table.id = some_other_table.id 

donde some_other_table tendría un solo campo (iDS) y todos los valores serían únicos

Cuestiones relacionadas