Errores de desarrollo de bases de datos cometidos por desarrolladores de aplicaciones [cerrado]

Errores de programación y diseño de bases de datos clave cometidos por los desarrolladores

• Diseño y uso egoísta de la base de datos. Los desarrolladores a menudo tratan la base de datos como su almacén de objetos persistentes personal sin tener en cuenta las necesidades de otros interesados en los datos. Esto también se aplica a los arquitectos de aplicaciones. El mal diseño de la base de datos y la integridad de los datos dificultan el trabajo de terceros con los datos y pueden aumentar sustancialmente los costos del ciclo de vida del sistema. Los informes y MIS tienden a ser un primo pobre en el diseño de aplicaciones y solo se hacen como una idea tardía.

• Abusar de datos desnormalizados. Exagerar los datos desnormalizados y tratar de mantenerlos dentro de la aplicación es una receta para problemas de integridad de datos. Utilice la desnormalización con moderación. No querer añadir un join a una consulta no es una excusa para desnormalizar.

• Miedo de escribir SQL. SQL no es ciencia espacial y en realidad es bastante bueno para hacer su trabajo. Las capas de asignación de O / R son bastante buenas para hacer el 95% de las consultas que son simples y encajan bien en ese modelo. A veces SQL es la mejor manera de hacer el trabajo.

• Políticas dogmáticas de 'Procedimientos No Almacenados'. Independientemente de si cree que los procedimientos almacenados son malos, este tipo de actitud dogmática no tiene lugar en un proyecto de software.

• No entiendo el diseño de la base de datos. La normalización es tu amiga y es no rocket ciencia. La unión y la cardinalidad son conceptos bastante simples: si está involucrado en el desarrollo de aplicaciones de base de datos, realmente no hay excusa para no entenderlos.

1. No usar el control de versiones en el esquema de la base de datos
2. Trabajando directamente contra una base de datos en vivo
3. No leer y comprender conceptos de bases de datos más avanzados (índices, índices agrupados, restricciones, vistas materializadas, etc.)
4. No se puede probar la escalabilidad ... los datos de prueba de solo 3 o 4 filas nunca le darán la imagen real del rendimiento real en vivo

Uso excesivo y/o dependencia de procedimientos almacenados.

Algunos desarrolladores de aplicaciones ven los procedimientos almacenados como una extensión directa del código de nivel medio/front-end. Esto parece ser un rasgo común en los desarrolladores de Microsoft Stack, (soy uno, pero he crecido fuera de él) y produce muchos procedimientos almacenados que realizan la lógica de negocio compleja y el procesamiento de flujo de trabajo. Es mucho mejor hacerlo en otro lugar.

Los procedimientos almacenados son útiles cuando se ha demostrado realmente que factor técnico requiere su uso (por ejemplo, rendimiento y seguridad) Por ejemplo, mantener la agregación/filtrado de grandes conjuntos de datos "cerca de los datos".

Recientemente tuve que ayudar a mantener y mejorar una gran aplicación de escritorio Delphi de la cual el 70% de la lógica de negocio y las reglas se implementaron en 1400 procedimientos almacenados de SQL Server (el resto en controladores de eventos de interfaz de usuario). Esto fue una pesadilla, principalmente debido a la dificultad de introducir pruebas unitarias efectivas a TSQL, falta de encapsulación y herramientas pobres (Depuradores, editores).

Trabajando con un equipo de Java en el pasado, rápidamente descubrí que a menudo ocurre lo contrario en ese entorno. Un arquitecto de Java me dijo una vez: "La base de datos es para datos, no para código.".

En estos días creo que es un error no considerar procs almacenados en absoluto, pero deben ser utilizados con moderación (no por defecto) en situaciones en las que proporcionan beneficios útiles (ver las otras respuestas).

Problema Número uno? Solo prueban en bases de datos de juguetes. Así que no tienen idea de que su SQL se arrastrará cuando la base de datos se haga grande, y alguien tiene que venir y arreglarlo más tarde (ese sonido que puedes escuchar es mi rechinar de dientes).

No se utilizan índices.

Rendimiento Deficiente Causado por Subconsultas Correlacionadas

La mayoría de las veces desea evitar subconsultas correlacionadas. Una subconsulta se correlaciona si, dentro de la subconsulta, hay una referencia a una columna de la consulta externa. Cuando esto sucede, la subconsulta se ejecuta al menos una vez por cada fila devuelta y podría ejecutarse más veces si se aplican otras condiciones después de aplicar la condición que contiene la subconsulta correlacionada.

Perdona el ejemplo artificial y la sintaxis de Oracle, pero digamos que quería encontrar todos los empleados que han sido contratados en cualquiera de sus tiendas desde la última vez que la tienda hizo menos de sales 10,000 de ventas en un día.

select e.first_name, e.last_name
from employee e
where e.start_date > 
        (select max(ds.transaction_date)
         from daily_sales ds
         where ds.store_id = e.store_id and
               ds.total < 10000)

La subconsulta en este ejemplo se correlaciona con la consulta externa por el store_id y se ejecutará para cada empleado en su sistema. Una forma de optimizar esta consulta es mover la subconsulta a una vista en línea.

select e.first_name, e.last_name
from employee e,
     (select ds.store_id,
             max(s.transaction_date) transaction_date
      from daily_sales ds
      where ds.total < 10000
      group by s.store_id) dsx
where e.store_id = dsx.store_id and
      e.start_date > dsx.transaction_date

En este ejemplo, la consulta en la cláusula from es ahora una vista en línea (de nuevo alguna sintaxis específica de Oracle) y solo se ejecuta una vez. Dependiendo de su modelo de datos, esta consulta probablemente se ejecutará mucho más rápido. Funcionaría mejor que la primera consulta a medida que aumentara el número de empleados. La primera consulta podría funcionar mejor si hubiera pocos empleados y muchas tiendas (y quizás muchas de las tiendas no tuvieran empleados) y la tabla daily_sales se indexara en store_id. Este no es un escenario probable, pero muestra cómo una consulta correlacionada podría posiblemente realizar mejor que una alternativa.

He visto desarrolladores junior correlacionar subconsultas muchas veces y por lo general ha tenido un impacto severo en el rendimiento. Sin embargo, al eliminar una subconsulta correlacionada, asegúrese de mirar el plan explain antes y después para asegurarse de que no está empeorando el rendimiento.

En mi experiencia:
No comunicarse con DBA experimentados.

Usando Access en lugar de una base de datos "real". Hay un montón de grandes bases de datos pequeñas e incluso gratuitas como SQL Express, MySQL , y SQLite que funcionarán y escalarán mucho mejor. Las aplicaciones a menudo necesitan escalar de maneras inesperadas.

Olvidarse de establecer relaciones entre las tablas. Recuerdo tener que limpiar esto cuando empecé a trabajar en mi empleador actual.

Usando Excel para almacenar (grandes cantidades de) datos.

He visto empresas que tienen miles de filas y utilizan varias hojas de trabajo (debido al límite de filas de 65535 en versiones anteriores de Excel).

Excel es muy adecuado para informes, presentación de datos y otras tareas, pero no debe ser tratado como una base de datos.

Me gustaría añadir: Favoreciendo el código "elegante" sobre el código de alto rendimiento. El código que funciona mejor contra bases de datos es a menudo feo a los ojos del desarrollador de aplicaciones.

Creer que el sinsentido sobre la optimización prematura. Las bases de datos deben tener en cuenta el rendimiento en el diseño original y en cualquier desarrollo posterior. El rendimiento es el 50% del diseño de la base de datos (el 40% es integridad de los datos y el último 10% es seguridad) en mi opinión. Bases de datos que no se construyen de abajo hacia arriba para realizar funcionará mal una vez que los usuarios reales y el tráfico real se colocan contra la base de datos. Optimización prematura no significa ninguna optimización! Esto no significa que deba escribir código que casi siempre funcionará mal porque lo encuentre más fácil (cursores, por ejemplo, que nunca se deben permitir en una base de datos de producción a menos que todo lo demás haya fallado). Significa que no necesitas mirar exprimir ese último poco de rendimiento hasta que lo necesites. Se sabe mucho sobre lo que funcionará mejor en ignorar esto en el diseño y el desarrollo es, en el mejor de los casos, miope.

No se utilizan consultas parametrizadas. Son muy útiles para detener la inyección SQL.

Este es un ejemplo específico de no desinfectar los datos de entrada, mencionado en otra respuesta.

Odio cuando los desarrolladores usan sentencias select anidadas o incluso funciones que devuelven el resultado de una sentencia select dentro de la porción "SELECT" de una consulta.

Estoy realmente sorprendido de no ver esto en ningún otro lugar aquí, tal vez lo pasé por alto, aunque @adam tiene un problema similar indicado.

Ejemplo:

SELECT
    (SELECT TOP 1 SomeValue FROM SomeTable WHERE SomeDate = c.Date ORDER BY SomeValue desc) As FirstVal
    ,(SELECT OtherValue FROM SomeOtherTable WHERE SomeOtherCriteria = c.Criteria) As SecondVal
FROM
    MyTable c

En este escenario, si MyTable devuelve 10000 filas, el resultado es como si la consulta solo ejecutara 20001 consultas, ya que tenía que ejecutar la consulta inicial más la consulta cada una de las otras tablas una vez por cada línea de resultado.

Los desarrolladores pueden salirse con la suya trabajando en un entorno de desarrollo donde solo devuelven unas pocas filas de datos y las sub tablas generalmente solo tienen una pequeña cantidad de datos, pero en un entorno de producción, este tipo de consulta puede ser exponencialmente costoso a medida que se agregan más datos a las tablas.

Un ejemplo mejor (no necesariamente perfecto) sería algo como:

SELECT
     s.SomeValue As FirstVal
    ,o.OtherValue As SecondVal
FROM
    MyTable c
    LEFT JOIN (
        SELECT SomeDate, MAX(SomeValue) as SomeValue
        FROM SomeTable 
        GROUP BY SomeDate
     ) s ON c.Date = s.SomeDate
    LEFT JOIN SomeOtherTable o ON c.Criteria = o.SomeOtherCriteria

Esto permite optimizadores de base de datos para barajar los datos juntos, en lugar de la solicitud en cada registro de la tabla principal y por lo general encuentro cuando tengo que arreglar el código donde se ha creado este problema, por lo general termino aumentando la velocidad de las consultas en un 100% o más, mientras que al mismo tiempo reduce el uso de CPU y memoria.

Para bases de datos basadas en SQL:

1. No aprovechar los ÍNDICES AGRUPADOS o elegir la(s) columna (s) incorrecta (s) para AGRUPAR.
2. No usar un tipo de datos SERIAL (autonumber) como CLAVE PRIMARIA para unirse a una CLAVE FORÁNEA (INT) en una relación de tabla padre/hijo.
3. No ACTUALIZAR ESTADÍSTICAS en una tabla cuando se han INSERTADO o ELIMINADO muchos registros.
4. No reorganizar (es decir, descargar, soltar, recrear, cargar y volver a indexar) tablas cuando se han insertado muchas filas o eliminadas (algunos motores mantienen físicamente las filas eliminadas en una tabla con un indicador eliminar.)
5. No aprovechar FRAGMENT ON EXPRESSION (si es compatible) en tablas grandes que tienen altas tasas de transacción.
6. ¡Elegir el tipo de datos incorrecto para una columna!
7. No elegir un nombre de columna apropiado.
8. No agregar nuevas columnas al final de la tabla.
9. No crear índices adecuados para soportar consultas de uso frecuente.
10. crear índices en columnas con pocas posibilidades valores y creación de índices innecesarios.
    ...más que añadir.

• No tomar una copia de seguridad antes de solucionar algún problema dentro de la base de datos de producción.

• Uso de comandos DDL en objetos almacenados (como tablas, vistas) en procedimientos almacenados.

• Miedo de usar el proc almacenado o miedo de usar consultas OR donde sea más eficiente / apropiado usar.

• Ignorar el uso de un generador de perfiles de base de datos, que puede decirle exactamente en qué se está convirtiendo su consulta OR y, por lo tanto, verificar la lógica o incluso para depuración cuando no se utiliza OR.

No haciendo el nivel correcto de normalización. Debe asegurarse de que los datos no se dupliquen y de que está dividiendo los datos en diferentes según sea necesario. También debe asegurarse de que no está siguiendo la normalización demasiado en la medida en que eso perjudicará el rendimiento.

Tratar la base de datos como un mecanismo de almacenamiento (es decir, biblioteca de colecciones glorificadas) y, por lo tanto, subordinada a su aplicación (ignorando otras aplicaciones que comparten los datos)

• Descartar un OR como Hibernar de la mano, por razones como "es demasiado mágico" o "no en mi base de datos".
• Confiando demasiado en un OR como Hibernar y tratando de calzarlo en donde no es apropiado.

1 - Usar innecesariamente una función en un valor en una cláusula where con el resultado de que no se usa ese índice.

Ejemplo:

where to_char(someDate,'YYYYMMDD') between :fromDate and :toDate

En lugar de

where someDate >= to_date(:fromDate,'YYYYMMDD') and someDate < to_date(:toDate,'YYYYMMDD')+1

Y en menor medida: No agregar índices funcionales a aquellos valores que los necesitan...

2 - No agregar restricciones de comprobación para garantizar la validez de los datos. Las restricciones pueden ser utilizadas por el optimizador de consultas, y realmente ayudan a garantizar que pueda confiar en sus invariantes. Hay simplemente no hay razón para no usarlos.

3 - Agregar columnas no normalizadas a las tablas por pura pereza o presión de tiempo. Las cosas generalmente no están diseñadas de esta manera, sino que evolucionan hacia esto. El resultado final, sin falta, es un montón de trabajo tratando de limpiar el desastre cuando te muerde la integridad de los datos perdidos en evoluciones futuras.

Piense en esto, una tabla sin datos es muy barata de rediseñar. Una mesa con un par de millones de registros sin integridad... no es tan barato rediseñar. Por lo tanto, hacer el diseño correcto al crear la columna o tabla se amortiza en picas.

4 - no tanto sobre la base de datos per se, pero de hecho molesto. No importa la calidad del código de SQL. El hecho de que su SQL se exprese en texto no hace que sea correcto ocultar la lógica en montones de algoritmos de manipulación de cadenas. Es perfectamente posible escribir SQL en texto de una manera que sea realmente legible por su compañero programador.

Esto se ha dicho antes, pero: índices, índices, índices. He visto muchos casos de aplicaciones web empresariales de bajo rendimiento que se arreglaron simplemente haciendo un poco de perfil (para ver qué tablas se estaban golpeando mucho), y luego agregar un índice en esas tablas. Esto ni siquiera requiere mucho en el camino del conocimiento de escritura SQL, y la recompensa es enorme.

Evite la duplicación de datos como la plaga. Algunas personas abogan por que un poco de duplicación no hará daño, y lo hará mejorar el rendimiento. Oye, no estoy diciendo que tengas que torturar tu esquema en Tercera Forma Normal, hasta que sea tan abstracto que ni siquiera los DBA sepan lo que está pasando. Solo entienda que cada vez que duplique un conjunto de nombres, códigos postales o códigos de envío, las copias se desconectarán entre sí eventualmente. Sucederá. Y luego te estarás pateando mientras ejecutas el script de mantenimiento semanal.

Y por último: use un nombre claro, consistente e intuitivo convención. De la misma manera que una pieza de código bien escrita debe ser legible, un buen esquema SQL o consulta debe ser legible y prácticamente decirle lo que está haciendo, incluso sin comentarios. Te lo agradecerás en seis meses, cuando tengas que hacer mantenimiento en las mesas. "SELECT account_number, billing_date FROM national_accounts" es infinitamente más fácil de trabajar que "SELECT ACCNTNBR, BILLDAT FROM NTNLACCTS".

No ejecutar una consulta SELECT correspondiente antes de ejecutar la consulta DELETE (particularmente en bases de datos de producción)!

El error más común que he visto en veinte años: no planificar con anticipación. Muchos desarrolladores crearán una base de datos y tablas, y luego modificarán y expandirán continuamente las tablas a medida que construyen las aplicaciones. El resultado final es a menudo un desastre e ineficiente y difícil de limpiar o simplificar más adelante.

A) Valores de consulta de Hardcoding en cadena
b) Poner el código de consulta de la base de datos en la acción "OnButtonPress" en una aplicación de Windows Forms

He visto ambos.

No prestar suficiente atención a la administración de conexiones de base de datos en su aplicación. Luego descubre que la aplicación, el equipo, el servidor y la red están obstruidos.

1. Pensando que son DBA y modeladores/diseñadores de datos cuando no tienen adoctrinamiento formal de ningún tipo en esas áreas.

2. Pensando que su proyecto no requiere un DBA porque todo eso es fácil / trivial.

3. No se puede discernir correctamente entre el trabajo que se debe hacer en la base de datos y el trabajo que se debe hacer en la aplicación.

4. No validar copias de seguridad, o no hacer copias de seguridad.

5. Incrustar SQL raw en su código.

Aquí hay un enlace al video llamado 'Errores clásicos de Desarrollo de Bases de datos y cinco formas de superarlos ' por Scott Walz

No tener una comprensión del modelo de concurrencia de bases de datos y cómo esto afecta el desarrollo. Es fácil agregar índices y modificar consultas después del hecho. Sin embargo, las aplicaciones diseñadas sin la debida consideración para los puntos de acceso, contención de recursos y el funcionamiento correcto (Suponiendo que lo que acaba de leer sigue siendo válido!) puede requerir cambios significativos dentro de la base de datos y el nivel de aplicación para corregirlos posteriormente.

No entiendo cómo funciona un DBMS bajo el capó.

No se puede conducir correctamente una palanca sin entender cómo funciona un embrague. Y no puede entender cómo usar una base de datos sin entender que realmente solo está escribiendo en un archivo en su disco duro.

Específicamente:

1. ¿Sabes lo que es un Índice Agrupado? ¿Lo pensaste cuando diseñaste tu esquema?

2. ¿Sabe utilizar correctamente los índices? Cuan ¿reutilizar un índice? ¿Sabes lo que es un Índice de Cobertura?

3. Genial, tienes índices. ¿Qué tan grande es 1 fila en su índice? ¿Qué tan grande será el índice cuando se tiene una gran cantidad de datos? ¿Eso encajará fácilmente en la memoria? Si no lo hace es inútil como índice.

4. ¿Alguna vez has usado EXPLAIN en MySQL? Gran. Ahora sé honesto contigo mismo: ¿Entendiste siquiera la mitad de lo que viste? No, probablemente no lo hiciste.

5. ¿Entiendes la Caché de Consultas? ¿Sabes qué hace que una consulta no sea accesible?

6. ¿Estás usando MyISAM? Si NECESITAS buscar texto completo, Myisam's es una mierda de todos modos. Usa Sphinx. Entonces cambia a Inno.

1. Usando un OR para hacer actualizaciones masivas
2. Seleccionar más datos de los necesarios. Una vez más, normalmente se hace cuando se usa un {
3. Disparando sql en bucle.
4. No tener buenos datos de prueba y notar la degradación del rendimiento solo en datos en vivo.