¿Cuáles son los antipatrones de SQL más comunes? [cerrado]

Todos los que trabajamos con bases de datos relacionales hemos aprendido (o estamos aprendiendo) que SQL es diferente. Obtener los resultados deseados, y hacerlo de manera eficiente, implica un proceso tedioso caracterizado en parte por aprender paradigmas desconocidos y descubrir que algunos de nuestros patrones de programación más familiares no funcionan aquí. ¿Cuáles son los antipatrones comunes que ha visto (o que usted mismo ha cometido)?

Dec 07 '08 02:12 dkretz

Estoy constantemente decepcionado por la tendencia de la mayoría de los programadores a mezclar su lógica de interfaz de usuario en la capa de acceso a datos:

SELECT
    FirstName + ' ' + LastName as "Full Name",
    case UserRole
        when 2 then "Admin"
        when 1 then "Moderator"
        else "User"
    end as "User's Role",
    case SignedIn
        when 0 then "Logged in"
        else "Logged out"
    end as "User signed in?",
    Convert(varchar(100), LastSignOn, 101) as "Last Sign On",
    DateDiff('d', LastSignOn, getDate()) as "Days since last sign on",
    AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' +
        City + ', ' + State + ' ' + Zip as "Address",
    'XXX-XX-' + Substring(
        Convert(varchar(9), SSN), 6, 4) as "Social Security #"
FROM Users

Normalmente, los programadores hacen esto porque tienen la intención de vincular su conjunto de datos directamente a una cuadrícula, y es conveniente tener formato SQL Server en el lado del servidor que en el cliente.

Consultas como la que se muestra arriba son extremadamente frágiles porque acoplan estrechamente la capa de datos a la capa de la interfaz de usuario. Además de eso, este estilo de programación impide por completo que los procedimientos almacenados sean reutilizables.

Dec 06 '2008 21:12 Juliet

Aquí está mi top 3.

Número 1. No especificar una lista de campos. (Editar: para evitar confusiones: esta es una regla del código de producción. No se aplica a scripts de análisis únicos, a menos que yo sea el autor).

SELECT *
Insert Into blah SELECT *

debiera ser

SELECT fieldlist
Insert Into blah (fieldlist) SELECT fieldlist

Número 2. Usando un cursor y un bucle while, cuando un bucle while con una variable de bucle será suficiente.

DECLARE @LoopVar int

SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable)
WHILE @LoopVar is not null
BEGIN
  -- Do Stuff with current value of @LoopVar
  ...
  --Ok, done, now get the next value
  SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable
    WHERE @LoopVar < TheKey)
END

Número 3. DateLogic a través de tipos de cadenas.

--Trim the time
Convert(Convert(theDate, varchar(10), 121), datetime)

Debiera ser

--Trim the time
DateAdd(dd, DateDiff(dd, 0, theDate), 0)

He visto un aumento reciente de "Una consulta es mejor que dos, ¿verdad?"

SELECT *
FROM blah
WHERE (blah.Name = @name OR @name is null)
  AND (blah.Purpose = @Purpose OR @Purpose is null)

Esta consulta requiere dos o tres planes de ejecución diferentes según los valores de los parámetros. Sólo se genera un plan de ejecución y se guarda en la memoria caché para este texto SQL. Ese plan se utilizará independientemente del valor de los parámetros. Esto da como resultado un rendimiento deficiente intermitente. Es mucho mejor escribir dos consultas (una consulta por plan de ejecución previsto).

Dec 06 '2008 19:12 Amy B

Campos de contraseña legibles por humanos , egad. Autoexplicativo.
Al usar LIKE en columnas indexadas, casi me siento tentado a decir LIKE en general.
Reciclaje de valores PK generados por SQL.
Sorpresa, nadie mencionó la mesa de dioses todavía. Nada dice "orgánico" como 100 columnas de indicadores de bits, cadenas grandes y números enteros.
Luego está el patrón "Extraño archivos .ini" : almacenar archivos CSV, cadenas delimitadas por tuberías u otros datos necesarios para el análisis en campos de texto grandes.
Y para el servidor MS SQL el uso de cursores . Hay una mejor manera de realizar cualquier tarea del cursor.

¡Editado porque hay tantos!

Dec 06 '2008 20:12

Usando alias de tablas sin sentido:

from employee t1,
department t2,
job t3,
...

Hace que leer una declaración SQL grande sea mucho más difícil de lo necesario

Dec 06 '2008 19:12