¿Cuáles son los antipatrones 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 que se caracteriza 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 has visto (o que has cometido)?

Me decepciona constantemente 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 el formato del servidor SQL en el lado del servidor que el formato en el cliente.

Las 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 evita a fondo que los procedimientos almacenados sean reutilizables.

Aquí están mis 3 mejores.

Número 1. Error al especificar una lista de campos. (Editar: para evitar confusiones: esta es una regla de código de producción. No se aplica a los 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 lo hará un bucle while con una variable de bucle.

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 cadena.

--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 pico 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. Solo se genera un plan de ejecución y se atasca en la memoria caché para este texto sql. Ese plan se utilizará independientemente del valor de los parámetros. Esto da como resultado un bajo rendimiento intermitente. Es mucho mejor escribir dos consultas (una consulta por plan de ejecución previsto).

• Campos de contraseña legibles por humanos , egad. Autoexplicativo.

• Utilizando LIKE contra columnas indexadas , estoy casi tentado a decir LIKE en general.

• Reciclaje de valores PK generados por SQL.

• Sorpresa, nadie mencionó la mesa de Dios todavía. Nada dice "orgánico" como 100 columnas de banderas de bits, cadenas grandes y enteros.

• Luego está el patrón "Echo de menos los archivos .ini" : almacenar CSV, cadenas delimitadas por tuberías u otros datos requeridos para analizar en campos de texto grandes.

• Y para el servidor MS SQL, el uso de cursores en absoluto . Hay una mejor manera de hacer cualquier tarea de cursor.

Editado porque hay tantos!

No tiene que profundizar en ello: no usar declaraciones preparadas.

Usando alias de tabla 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

var query = "select COUNT(*) from Users where UserName = '" 
            + tbUser.Text 
            + "' and Password = '" 
            + tbPassword.Text +"'";

1. Confiando ciegamente en la entrada del usuario
2. No usar consultas parametrizadas
3. Contraseñas de texto sin cifrar

Mis errores son las tablas de acceso de 450 columnas que ha preparado el hijo de 8 años de los mejores amigos del Director Gerente y la tabla de búsqueda dudosa que solo existe porque alguien no sabe cómo normalizar una estructura de datos correctamente.

Por lo general, esta tabla de búsqueda se ve así:

YO DINT,
Nombre NVARCHAR (132),
IntValue1 INT,
IntValue2 INT,
CharValue1 NVARCHAR (255),
CharValue2 NVARCHAR (255),
Date1 DATETIME,
Fecha2 FECHA

He perdido la cuenta de la cantidad de clientes que he visto que tienen sistemas que dependen de abominaciones como esta.

Los que más me disgustan son

1. Uso de espacios al crear tablas, sprocs, etc. Estoy bien con CamelCase o under_scores y singular o plural y MAYÚSCULAS o minúsculas, pero tengo que referirme a una tabla o columna [con espacios], especialmente si [está espaciado de manera extraña] (sí, Me he encontrado con esto) realmente me irrita.

2. Datos desnormalizados. Una tabla no tiene que estar perfectamente normalizada, pero cuando me encuentro con una tabla de empleados que tiene información sobre su puntaje de evaluación actual o su principal, me dice que probablemente necesite hacer una tabla separada en algún momento y luego trate de mantenerlos sincronizados. Normalizaré los datos primero y luego, si veo un lugar donde la desnormalización ayuda, lo consideraré.

3. Uso excesivo de vistas o cursores. Las vistas tienen un propósito, pero cuando cada tabla está envuelta en una vista, es demasiado. He tenido que usar cursores varias veces, pero generalmente puedes usar otros mecanismos para esto.

4. Acceso. ¿Puede un programa ser un antipatrón? Tenemos SQL Server en mi trabajo, pero varias personas usan el acceso debido a su disponibilidad, "facilidad de uso" y "amabilidad" para usuarios no técnicos. Aquí hay demasiado para entrar, pero si has estado en un entorno similar, ya sabes.

use SP como prefijo del nombre del procedimiento de tienda porque primero buscará en la ubicación de procedimientos del sistema en lugar de los personalizados.

Uso excesivo de tablas y cursores temporales.

Para almacenar valores de tiempo, solo se debe usar la zona horaria UTC. La hora local no debe ser utilizada.

usando @@ IDENTITY en lugar de SCOPE_IDENTITY ()

Citado de esta respuesta :

• @@ IDENTITY devuelve el último valor de identidad generado para cualquier tabla en la sesión actual, en todos los ámbitos. Debe tener cuidado aquí, ya que está en todos los ámbitos. Podría obtener un valor de un activador, en lugar de su declaración actual.
• SCOPE_IDENTITY devuelve el último valor de identidad generado para cualquier tabla en la sesión actual y el alcance actual. Generalmente lo que quieres usar.
• IDENT_CURRENT devuelve el último valor de identidad generado para una tabla específica en cualquier sesión y cualquier ámbito. Esto le permite especificar de qué tabla desea el valor, en caso de que los dos anteriores no sean exactamente lo que necesita (muy raro). Puede usar esto si desea obtener el valor de IDENTIDAD actual para una tabla en la que no ha insertado un registro.

Reutilizar un campo 'muerto' para algo para lo que no estaba destinado (por ejemplo, almacenar datos de usuario en un campo 'Fax'), ¡aunque es muy tentador como una solución rápida!

select some_column, ...
from some_table
group by some_column

y suponiendo que el resultado se ordenará por some_column. He visto esto un poco con Sybase donde se cumple el supuesto (por ahora).

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

O bien, agrupando todo en una sola línea.

• La FROM TableA, TableB WHEREsintaxis de JOINS en lugar deFROM TableA INNER JOIN TableB ON

• Suponiendo que una consulta se devolverá ordenada de cierta manera sin poner una cláusula ORDER BY, solo porque esa fue la forma en que se mostró durante la prueba en la herramienta de consulta.

Aprender SQL en los primeros seis meses de su carrera y nunca aprender nada más durante los próximos 10 años. En particular, no aprender o usar eficazmente las funciones de SQL analítico / ventanas. En particular, el uso de over () y la partición por.

Las funciones de ventana, como las funciones de agregado, realizan una agregación en un conjunto definido (un grupo) de filas, pero en lugar de devolver un valor por grupo, las funciones de ventana pueden devolver múltiples valores para cada grupo.

Consulte el Apéndice A del O'Reilly SQL Cookbook para obtener una buena descripción de las funciones de ventanas.

Necesito poner mi propio favorito actual aquí, solo para completar la lista. Mi antipatrón favorito no prueba tus consultas .

Esto aplica cuando:

1. Su consulta involucra más de una tabla.
2. Cree que tiene un diseño óptimo para una consulta, pero no se moleste en probar sus suposiciones.
3. Acepta la primera consulta que funciona, sin tener idea de si está incluso cerca de optimizada.

Y cualquier prueba realizada contra datos atípicos o insuficientes no cuenta. Si se trata de un procedimiento almacenado, coloque la declaración de prueba en un comentario y guárdela con los resultados. De lo contrario, póngalo en un comentario en el código con los resultados.

Abuso de mesa temporal.

Específicamente este tipo de cosas:

SELECT personid, firstname, lastname, age
INTO #tmpPeople
FROM People
WHERE lastname like 's%'

DELETE FROM #tmpPeople
WHERE firstname = 'John'

DELETE FROM #tmpPeople
WHERE firstname = 'Jon'

DELETE FROM #tmpPeople
WHERE age > 35

UPDATE People
SET firstname = 'Fred'
WHERE personid IN (SELECT personid from #tmpPeople)

No cree una tabla temporal a partir de una consulta, solo para eliminar las filas que no necesita.

Y sí, he visto páginas de código de esta forma en bases de datos de producción.

Visión contraria: obsesión excesiva con la normalización.

La mayoría de los sistemas SQL / RBDB ofrecen muchas características (transacciones, replicación) que son bastante útiles, incluso con datos no normalizados. El espacio en disco es barato y, a veces, puede ser más simple (código más fácil, tiempo de desarrollo más rápido) manipular / filtrar / buscar datos recuperados, que escribir un esquema 1NF y lidiar con todas las molestias (uniones complejas, subselecciones desagradables) , etc.)

He descubierto que los sistemas sobre normalizados suelen ser una optimización prematura, especialmente durante las primeras etapas de desarrollo.

(más pensamientos sobre él ... http://writeonly.wordpress.com/2008/12/05/simple-object-db-using-json-and-python-sqlite/ )

Acabo de armar este, basado en algunas de las respuestas SQL aquí en SO.

Es un antipatrón serio pensar que los desencadenantes son a las bases de datos como lo son los controladores de eventos a OOP. Existe la percepción de que cualquier lógica antigua se puede poner en disparadores, para que se active cuando una transacción (evento) ocurre en una mesa.

No es verdad. Una de las grandes diferencias es que los disparadores son síncronos, con una venganza, porque son síncronos en una operación de configuración, no en una operación de fila. En el lado OOP, exactamente lo contrario: los eventos son una forma eficiente de implementar transacciones asincrónicas.

Procedimientos almacenados o funciones sin ningún comentario ...

1) No sé si es un antipatrón "oficial", pero no me gusta e intento evitar los literales de cadena como valores mágicos en una columna de base de datos.

Un ejemplo de la tabla 'imagen' de MediaWiki:

img_media_type ENUM("UNKNOWN", "BITMAP", "DRAWING", "AUDIO", "VIDEO", 
    "MULTIMEDIA", "OFFICE", "TEXT", "EXECUTABLE", "ARCHIVE") default NULL,
img_major_mime ENUM("unknown", "application", "audio", "image", "text", 
    "video", "message", "model", "multipart") NOT NULL default "unknown",

(Acabo de notar una carcasa diferente, otra cosa para evitar)

Diseño casos como búsquedas int en tablas ImageMediaType e ImageMajorMime con claves primarias int.

2) conversión de fecha / cadena que se basa en configuraciones específicas de NLS

CONVERT(NVARCHAR, GETDATE())

sin identificador de formato

Subconsultas idénticas en una consulta.

• La vista alterada: una vista que se modifica con demasiada frecuencia y sin previo aviso ni razón. El cambio se notará en el momento más inapropiado o, peor aún, se equivocará y nunca se notará. Tal vez su aplicación se interrumpirá porque alguien pensó en un mejor nombre para esa columna. Como norma, las vistas deberían ampliar la utilidad de las tablas base mientras se mantiene un contrato con los consumidores. Solucione problemas pero no agregue características o peor cambie el comportamiento, para eso cree una nueva vista. Para mitigar, no comparta vistas con otros proyectos y use CTE cuando las plataformas lo permitan. Si su tienda tiene un DBA, probablemente no pueda cambiar las vistas, pero todas sus vistas estarán desactualizadas o serán inútiles en ese caso.

• The! Paramed: ¿Puede una consulta tener más de un propósito? Probablemente, pero la próxima persona que lo lea no lo sabrá hasta la meditación profunda. Incluso si no los necesita en este momento, es probable que lo haga, incluso si es "solo" para depurar. Agregar parámetros reduce el tiempo de mantenimiento y mantiene las cosas SECAS. Si tiene una cláusula where, debe tener parámetros.

• El caso para no CASE -

  SELECT  
  CASE @problem  
    WHEN 'Need to replace column A with this medium to large collection of strings hanging out in my code.'  
      THEN 'Create a table for lookup and add to your from clause.'  
    WHEN 'Scrubbing values in the result set based on some business rules.'  
      THEN 'Fix the data in the database'  
    WHEN 'Formating dates or numbers.'   
      THEN 'Apply formating in the presentation layer.'  
    WHEN 'Createing a cross tab'  
      THEN 'Good, but in reporting you should probably be using cross tab, matrix or pivot templates'   
  ELSE 'You probably found another case for no CASE but now I have to edit my code instead of enriching the data...' END  

Los dos que más encuentro y que pueden tener un costo significativo en términos de rendimiento son:

• Usar cursores en lugar de una expresión basada en conjuntos. Supongo que esto ocurre con frecuencia cuando el programador está pensando con procedimientos.

• Usando subconsultas correlacionadas, cuando una unión a una tabla derivada puede hacer el trabajo.

Poner cosas en tablas temporales, especialmente las personas que cambian de SQL Server a Oracle tienen la costumbre de usar en exceso las tablas temporales. Solo usa sentencias select anidadas.

Desarrolladores que escriben consultas sin tener una buena idea sobre qué hace que las aplicaciones SQL (tanto consultas individuales como sistemas multiusuario) sean rápidas o lentas. Esto incluye ignorancia sobre:

• estrategias físicas de minimización de E / S, dado que el cuello de botella de la mayoría de las consultas es E / S, no CPU
• Impacto del rendimiento de diferentes tipos de acceso al almacenamiento físico (por ejemplo, muchas E / S secuenciales serán más rápidas que muchas E / S aleatorias pequeñas, ¡aunque menos si su almacenamiento físico es un SSD!)
• cómo ajustar manualmente una consulta si el DBMS produce un plan de consulta deficiente
• cómo diagnosticar el bajo rendimiento de la base de datos, cómo "depurar" una consulta lenta y cómo leer un plan de consulta (o EXPLICAR, según el DBMS que elija)
• estrategias de bloqueo para optimizar el rendimiento y evitar puntos muertos en aplicaciones multiusuario
• importancia del procesamiento por lotes y otros trucos para manejar el procesamiento de conjuntos de datos
• diseño de tablas e índices para equilibrar mejor el espacio y el rendimiento (por ejemplo, cubriendo índices, manteniendo índices pequeños cuando sea posible, reduciendo los tipos de datos al tamaño mínimo necesario, etc.)

Usar SQL como un paquete ISAM (Método de acceso secuencial indexado) glorificado. En particular, anidar cursores en lugar de combinar declaraciones SQL en una sola declaración, aunque más grande. Esto también cuenta como 'abuso del optimizador' ya que de hecho no hay mucho que pueda hacer el optimizador. Esto se puede combinar con declaraciones no preparadas para la máxima ineficiencia:

DECLARE c1 CURSOR FOR SELECT Col1, Col2, Col3 FROM Table1

FOREACH c1 INTO a.col1, a.col2, a.col3
    DECLARE c2 CURSOR FOR
        SELECT Item1, Item2, Item3
            FROM Table2
            WHERE Table2.Item1 = a.col2
    FOREACH c2 INTO b.item1, b.item2, b.item3
        ...process data from records a and b...
    END FOREACH
END FOREACH

La solución correcta (casi siempre) es combinar las dos instrucciones SELECT en una:

DECLARE c1 CURSOR FOR
    SELECT Col1, Col2, Col3, Item1, Item2, Item3
        FROM Table1, Table2
        WHERE Table2.Item1 = Table1.Col2
        -- ORDER BY Table1.Col1, Table2.Item1

FOREACH c1 INTO a.col1, a.col2, a.col3, b.item1, b.item2, b.item3
    ...process data from records a and b...
END FOREACH

La única ventaja de la versión de doble bucle es que puede detectar fácilmente los saltos entre los valores en la Tabla 1 porque el bucle interno termina. Esto puede ser un factor en los informes de interrupción de control.

Además, la clasificación en la aplicación suele ser un no-no.

Usando claves primarias como un sustituto para direcciones de registro y usando claves externas como un sustituto para punteros incrustados en registros.