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

¿Cuáles son los errores comunes de desarrollo de bases de datos cometidos por los desarrolladores de aplicaciones?

1. No usar índices apropiados

Esta es relativamente fácil pero aún sucede todo el tiempo. Las claves foráneas deben tener índices en ellas. Si está utilizando un campo en un WHERE(probablemente) debería tener un índice en él. Dichos índices a menudo deberían cubrir varias columnas en función de las consultas que necesita ejecutar.

2. No hacer cumplir la integridad referencial

Su base de datos puede variar aquí, pero si su base de datos admite integridad referencial, lo que significa que se garantiza que todas las claves externas apuntan a una entidad que existe, debería usarla.

Es bastante común ver esta falla en las bases de datos MySQL. No creo que MyISAM lo admita. InnoDB lo hace. Encontrará personas que usan MyISAM o aquellas que usan InnoDB pero que no lo están usando de todos modos.

Más aquí:

• ¿Qué importancia tienen las restricciones como NOT NULL y FOREIGN KEY si siempre controlaré la entrada de mi base de datos con php?
• ¿Son realmente necesarias las claves foráneas en el diseño de una base de datos?
• ¿Son realmente necesarias las claves foráneas en el diseño de una base de datos?

3. Uso de claves primarias naturales en lugar de sustitutas (técnicas)

Las claves naturales son claves basadas en datos significativos externos que son (aparentemente) únicos. Ejemplos comunes son códigos de productos, códigos de estado de dos letras (EE. UU.), Números de seguridad social, etc. Las claves primarias sustitutas o técnicas son aquellas que no tienen absolutamente ningún significado fuera del sistema. Se inventan exclusivamente para identificar la entidad y, por lo general, son campos de incremento automático (SQL Server, MySQL, otros) o secuencias (especialmente Oracle).

En mi opinión, siempre debes usar claves sustitutas. Este problema ha surgido en estas preguntas:

• ¿Cómo te gustan tus claves principales?
• ¿Cuál es la mejor práctica para las claves primarias en las tablas?
• Qué formato de clave primaria usaría en esta situación.
• Sustituto vs. claves naturales / comerciales
• ¿Debería tener un campo de clave principal dedicado?

Este es un tema algo controvertido sobre el que no obtendrá un acuerdo universal. Si bien puede encontrar algunas personas, que piensan que las claves naturales están bien en algunas situaciones, no encontrará ninguna crítica a las claves sustitutivas que no sean posiblemente innecesarias. Eso es un pequeño inconveniente si me preguntas.

Recuerde, incluso los países pueden dejar de existir (por ejemplo, Yugoslavia).

4. Escribir consultas que requieren DISTINCTtrabajar

A menudo ve esto en consultas generadas por ORM. Mire la salida del registro de Hibernate y verá que todas las consultas comienzan con:

SELECT DISTINCT ...

Este es un atajo para garantizar que no devuelva filas duplicadas y, por lo tanto, obtenga objetos duplicados. A veces verás gente haciendo esto también. Si lo ves demasiado, es una verdadera bandera roja. No DISTINCTes que sea ​​malo o no tenga aplicaciones válidas. Lo hace (en ambos casos) pero no es un sustituto o un recurso provisional para escribir consultas correctas.

Por qué odio DISTINCT :

En mi opinión, cuando las cosas comienzan a empeorar es cuando un desarrollador está creando consultas sustanciales, uniendo tablas, y de repente se da cuenta de que parece que está obteniendo filas duplicadas (o incluso más) y su respuesta inmediata ... su "solución" a este "problema" es lanzar la palabra clave DISTINCT y POOF todos sus problemas desaparecen.

5. Favorecer la agregación sobre las uniones

Otro error común de los desarrolladores de aplicaciones de bases de datos es no darse cuenta de cuánto GROUP BYse puede comparar la agregación más costosa (es decir, la cláusula) con las uniones.

Para darle una idea de cuán extendido está esto, he escrito sobre este tema varias veces aquí y me han rechazado mucho. Por ejemplo:

De la instrucción SQL: "unirse" frente a "agrupar por y que tiene" :

Primera consulta:

SELECT userid
FROM userrole
WHERE roleid IN (1, 2, 3)
GROUP by userid
HAVING COUNT(1) = 3

Tiempo de consulta: 0.312 s

Segunda consulta:

SELECT t1.userid
FROM userrole t1
JOIN userrole t2 ON t1.userid = t2.userid AND t2.roleid = 2
JOIN userrole t3 ON t2.userid = t3.userid AND t3.roleid = 3
AND t1.roleid = 1

Tiempo de consulta: 0.016 s

Así es. La versión de unión que propuse es veinte veces más rápida que la versión agregada.

6. No simplificar consultas complejas a través de vistas

No todos los proveedores de bases de datos admiten vistas, pero para aquellos que lo hacen, pueden simplificar enormemente las consultas si se usan con prudencia. Por ejemplo, en un proyecto utilicé un modelo genérico de Party para CRM. Esta es una técnica de modelado extremadamente potente y flexible, pero puede conducir a muchas uniones. En este modelo había:

• Partido : personas y organizaciones;
• Rol de la fiesta : cosas que hicieron esas partes, por ejemplo, Empleado y Empleador;
• Relación de roles de partido : cómo esos roles se relacionan entre sí.

Ejemplo:

• Ted es una Persona, siendo un subtipo de Partido;
• Ted tiene muchos roles, uno de los cuales es Empleado;
• Intel es una organización, que es un subtipo de una Parte;
• Intel tiene muchos roles, uno de los cuales es Empleador;
• Intel emplea a Ted, lo que significa que existe una relación entre sus respectivos roles.

Entonces, hay cinco tablas unidas para vincular a Ted con su empleador. Asume que todos los empleados son Personas (no organizaciones) y proporciona esta vista auxiliar:

CREATE VIEW vw_employee AS
SELECT p.title, p.given_names, p.surname, p.date_of_birth, p2.party_name employer_name
FROM person p
JOIN party py ON py.id = p.id
JOIN party_role child ON p.id = child.party_id
JOIN party_role_relationship prr ON child.id = prr.child_id AND prr.type = 'EMPLOYMENT'
JOIN party_role parent ON parent.id = prr.parent_id = parent.id
JOIN party p2 ON parent.party_id = p2.id

Y de repente tiene una vista muy simple de los datos que desea, pero en un modelo de datos altamente flexible.

7. No desinfección de entrada

Este es uno enorme. Ahora me gusta PHP, pero si no sabes lo que estás haciendo, es muy fácil crear sitios vulnerables a los ataques. Nada lo resume mejor que la historia de las pequeñas Bobby Tables .

Los datos proporcionados por el usuario a través de URL, datos de formulario y cookies siempre deben tratarse como hostiles y desinfectados. Asegúrese de obtener lo que espera.

8. No usar declaraciones preparadas

Las declaraciones preparadas son cuando compila una consulta menos los datos utilizados en inserciones, actualizaciones y WHEREcláusulas y luego la proporciona más tarde. Por ejemplo:

SELECT * FROM users WHERE username = 'bob'

vs

SELECT * FROM users WHERE username = ?

o

SELECT * FROM users WHERE username = :username

Dependiendo de su plataforma.

He visto bases de datos arrodilladas al hacer esto. Básicamente, cada vez que una base de datos moderna encuentra una nueva consulta, tiene que compilarla. Si encuentra una consulta que se ha visto antes, le está dando a la base de datos la oportunidad de almacenar en caché la consulta compilada y el plan de ejecución. Al hacer mucho la consulta, le está dando a la base de datos la oportunidad de resolverlo y optimizarlo en consecuencia (por ejemplo, al anclar la consulta compilada en la memoria).

El uso de declaraciones preparadas también le dará estadísticas significativas sobre la frecuencia con la que se usan ciertas consultas.

Las declaraciones preparadas también lo protegerán mejor contra los ataques de inyección SQL.

9. No se normaliza lo suficiente

La normalización de la base de datos es básicamente el proceso de optimizar el diseño de la base de datos o cómo organizar sus datos en tablas.

Justo esta semana me encontré con un código en el que alguien había implosionado una matriz y la había insertado en un solo campo en una base de datos. Normalizar eso sería tratar el elemento de esa matriz como una fila separada en una tabla secundaria (es decir, una relación de uno a muchos).

Esto también apareció en el mejor método para almacenar una lista de ID de usuario :

He visto en otros sistemas que la lista se almacena en una matriz PHP serializada.

Pero la falta de normalización viene en muchas formas.

Más:

• Normalización: ¿Qué tan lejos es lo suficientemente lejos?
• SQL por diseño: por qué necesita la normalización de la base de datos

10. Normalizando demasiado

Esto puede parecer una contradicción con el punto anterior, pero la normalización, como muchas cosas, es una herramienta. Es un medio para un fin y no un fin en sí mismo. Creo que muchos desarrolladores olvidan esto y comienzan a tratar un "medio" como un "fin". Las pruebas unitarias son un excelente ejemplo de esto.

Una vez trabajé en un sistema que tenía una gran jerarquía para clientes que era algo así como:

Licensee ->  Dealer Group -> Company -> Practice -> ...

de modo que tenía que unir unas 11 tablas antes de poder obtener datos significativos. Fue un buen ejemplo de normalización llevado demasiado lejos.

Más concretamente, la desnormalización cuidadosa y considerada puede tener enormes beneficios de rendimiento, pero debe tener mucho cuidado al hacer esto.

Más:

• ¿Por qué demasiada normalización de la base de datos puede ser algo malo?
• ¿Hasta dónde llevar la normalización en el diseño de bases de datos?
• Cuándo no normalizar su base de datos SQL
• Quizás normalizar no es normal
• La madre de todos los debates de normalización de bases de datos sobre el horror de codificación

11. Usando arcos exclusivos

Un arco exclusivo es un error común cuando se crea una tabla con dos o más claves foráneas donde una y solo una de ellas puede ser no nula. Gran error. Por un lado, se vuelve mucho más difícil mantener la integridad de los datos. Después de todo, incluso con integridad referencial, nada impide que se configuren dos o más de estas claves foráneas (a pesar de las complejas restricciones de verificación).

De una guía práctica para el diseño de bases de datos relacionales :

Hemos desaconsejado encarecidamente la construcción de arcos exclusivos siempre que sea posible, por la buena razón de que pueden ser incómodos escribir código y plantear más dificultades de mantenimiento.

12. No hacer análisis de rendimiento en consultas en absoluto

El pragmatismo reina supremamente, particularmente en el mundo de las bases de datos. Si te apegas a los principios hasta el punto de que se han convertido en un dogma, entonces probablemente hayas cometido errores. Tome el ejemplo de las consultas agregadas de arriba. La versión agregada puede parecer "agradable" pero su rendimiento es lamentable. Una comparación de rendimiento debería haber terminado el debate (pero no lo hizo), pero más importante: decir esas opiniones mal informadas en primer lugar es ignorante, incluso peligroso.

13. Dependencia excesiva de UNION ALL y particularmente de las construcciones UNION

Una UNIÓN en términos de SQL simplemente concatena conjuntos de datos congruentes, lo que significa que tienen el mismo tipo y número de columnas. La diferencia entre ellos es que UNION ALL es una concatenación simple y debe preferirse siempre que sea posible, mientras que UNION hará una DISTINCIÓN implícita para eliminar las tuplas duplicadas.

Los SINDICATOS, como DISTINCT, tienen su lugar. Hay aplicaciones válidas Pero si te encuentras haciendo muchas de ellas, particularmente en subconsultas, entonces probablemente estés haciendo algo mal. Ese podría ser un caso de construcción de consulta deficiente o un modelo de datos mal diseñado que lo obligue a hacer tales cosas.

Los UNION, particularmente cuando se usan en uniones o subconsultas dependientes, pueden paralizar una base de datos. Intenta evitarlos siempre que sea posible.

14. Uso de condiciones OR en consultas

Esto puede parecer inofensivo. Después de todo, los AND están bien. O debería estar bien también ¿verdad? Incorrecto. Básicamente, una condición AND restringe el conjunto de datos mientras que una condición OR lo hace crecer , pero no de una manera que se preste a la optimización. Particularmente cuando las diferentes condiciones OR pueden cruzarse, forzando al optimizador a una operación DISTINCT con eficacia en el resultado.

Malo:

... WHERE a = 2 OR a = 5 OR a = 11

Mejor:

... WHERE a IN (2, 5, 11)

Ahora su optimizador SQL puede convertir efectivamente la primera consulta en la segunda. Pero puede que no. Solo no lo hagas.

15. No diseñar su modelo de datos para prestarse a soluciones de alto rendimiento

Este es un punto difícil de cuantificar. Normalmente se observa por su efecto. Si se encuentra escribiendo consultas retorcidas para tareas relativamente simples o si las consultas para encontrar información relativamente sencilla no son eficientes, entonces probablemente tenga un modelo de datos deficiente.

De alguna manera, este punto resume todos los anteriores, pero es más una advertencia que hacer cosas como la optimización de consultas a menudo se hace primero cuando debería hacerse en segundo lugar. En primer lugar, debe asegurarse de tener un buen modelo de datos antes de intentar optimizar el rendimiento. Como dijo Knuth:

La optimización temprana es la raíz de todo mal

16. Uso incorrecto de las transacciones de la base de datos

Todos los cambios de datos para un proceso específico deben ser atómicos. Es decir, si la operación tiene éxito, lo hace completamente. Si falla, los datos se dejan sin cambios. - No debería haber posibilidad de cambios 'a medio hacer'.

Idealmente, la forma más sencilla de lograr esto es que todo el diseño del sistema debe esforzarse por admitir todos los cambios de datos a través de declaraciones individuales INSERT / UPDATE / DELETE. En este caso, no se necesita un manejo de transacciones especial, ya que su motor de base de datos debería hacerlo automáticamente.

Sin embargo, si algún proceso requiere que se realicen múltiples declaraciones como una unidad para mantener los datos en un estado consistente, entonces es necesario el Control de Transacción apropiado.

• Comience una transacción antes de la primera declaración.
• Confirmar la transacción después de la última declaración.
• En cualquier error, deshaga la transacción. Y muy NB! No olvide omitir / cancelar todas las declaraciones que siguen después del error.

También se recomienda prestar especial atención a las sutilezas de cómo la capa de conectividad de la base de datos y el motor de la base de datos interactúan a este respecto.

17. No entender el paradigma "basado en conjuntos"

El lenguaje SQL sigue un paradigma específico adecuado para tipos específicos de problemas. A pesar de varias extensiones específicas del proveedor, el lenguaje tiene dificultades para lidiar con problemas que son triviales en idiomas como Java, C #, Delphi, etc.

Esta falta de comprensión se manifiesta de varias maneras.

• Imponer inadecuadamente demasiada lógica de procedimiento o imperativa en la base de datos.
• Uso inapropiado o excesivo de cursores. Especialmente cuando una sola consulta sería suficiente.
• Asumiendo incorrectamente que desencadena el fuego una vez por fila afectada en las actualizaciones de varias filas.

Determine una división clara de la responsabilidad y procure utilizar la herramienta adecuada para resolver cada problema.

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

• Diseño y uso de bases de datos egoístas. Los desarrolladores a menudo tratan la base de datos como su almacén personal de objetos persistentes sin tener en cuenta las necesidades de otros interesados ​​en los datos. Esto también se aplica a los arquitectos de aplicaciones. El diseño deficiente de la base de datos y la integridad de los datos dificultan que terceros trabajen 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 ocurrencia tardía.

• Abusar de datos desnormalizados. Exagerar los datos desnormalizados e intentar mantenerlos dentro de la aplicación es una receta para los problemas de integridad de los datos. Use la desnormalización con moderación. No querer agregar una unión a una consulta no es una excusa para denormalizar.

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

• Políticas dogmáticas de "procedimientos no almacenados". Independientemente de si crees que los procedimientos almacenados son malos, este tipo de actitud dogmática no tiene cabida en un proyecto de software.

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

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 probar la escalabilidad ... los datos de prueba de solo 3 o 4 filas nunca le darán una 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 pila de Microsoft (soy uno, pero he superado) y produce muchos procedimientos almacenados que realizan una lógica empresarial compleja y un procesamiento de flujo de trabajo. Esto se hace mucho mejor en otro lugar.

Los procedimientos almacenados son útiles cuando se ha comprobado que algún factor técnico real necesita 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 y las reglas del negocio se implementaron en 1400 procedimientos almacenados de SQL Server (el resto en los controladores de eventos de la interfaz de usuario). Esto fue una pesadilla, principalmente debido a la dificultad de introducir pruebas unitarias efectivas en TSQL, falta de encapsulación y herramientas deficientes (depuradores, editores).

Trabajando con un equipo de Java en el pasado, descubrí rápidamente que a menudo ocurre todo 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 tener en cuenta los procedimientos almacenados, pero deberían usarse con moderación (no de forma predeterminada) en situaciones en las que proporcionan beneficios útiles (ver las otras respuestas).

Problema número uno? Solo prueban en bases de datos de juguetes. Por lo tanto, no tienen idea de que su SQL se arrastrará cuando la base de datos crezca, y alguien tiene que venir y arreglarlo más tarde (ese sonido que puedes escuchar es el rechinar de mis dientes).

No usar índices.

Bajo rendimiento causado por subconsultas correlacionadas

La mayoría de las veces desea evitar subconsultas correlacionadas. Una subconsulta está correlacionada 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.

Perdone el ejemplo artificial y la sintaxis de Oracle, pero supongamos que desea encontrar a todos los empleados que han sido contratados en cualquiera de sus tiendas desde la última vez que la tienda realizó menos de $ 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 está correlacionada con la consulta externa por 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 ahora es una vista en línea (nuevamente una 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 aumentaba el número de empleados. La primera consulta podría funcionar mejor si hubiera pocos empleados y muchas tiendas (y tal vez muchas de las tiendas no tenían empleados) y la tabla daily_sales se indexó en store_id. Este no es un escenario probable, pero muestra cómo una consulta correlacionada podría funcionar mejor que una alternativa.

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

En mi experiencia:
no se comunica con DBA con experiencia.

Usar Access en lugar de una base de datos "real". Hay muchas 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 haber tenido que limpiar esto cuando comencé a trabajar en mi empleador actual.

Uso de Excel para almacenar (grandes cantidades de) datos.

He visto compañías que tienen miles de filas y usan múltiples 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 tratarse como una base de datos.

Me gustaría agregar: Favorecer el código "Elegante" sobre el código de alto rendimiento. El código que funciona mejor contra las bases de datos suele ser feo para el desarrollador de aplicaciones.

Creyendo esas tonterías sobre la optimización prematura. Las bases de datos deben considerar 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 datos y el último 10% es seguridad) en mi opinión. Las bases de datos que no se crean de abajo hacia arriba funcionarán mal una vez que los usuarios reales y el tráfico real se coloquen en la base de datos. ¡La optimización prematura no significa que no haya optimización! No significa que deba escribir código que casi siempre funcionará mal porque le resulta más fácil (por ejemplo, cursores que nunca deberían permitirse en una base de datos de producción a menos que todo lo demás haya fallado). Significa que no necesita buscar exprimir ese último pequeño rendimiento hasta que lo necesite. Se sabe mucho sobre qué funcionará mejor en las bases de datos,

No utiliza consultas parametrizadas. Son bastante útiles para detener la inyección de SQL .

Este es un ejemplo específico de no desinfectar los datos de entrada, mencionados 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 parte "SELECCIONAR" 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 acabara de ejecutar consultas 20001, ya que tenía que ejecutar la consulta inicial más la consulta de cada una de las otras tablas una vez para cada línea de resultado.

Los desarrolladores pueden salirse con la suya trabajando en un entorno de desarrollo en el que solo devuelven unas pocas filas de datos y las subtablas generalmente solo tienen una pequeña cantidad de datos, pero en un entorno de producción, este tipo de consulta puede volverse exponencialmente costoso a medida que aumenta los datos se agregan 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 que los optimizadores de bases de datos mezclen los datos juntos, en lugar de consultar en cada registro de la tabla principal y generalmente encuentro cuando tengo que arreglar el código donde se creó este problema, generalmente termino aumentando la velocidad de las consultas en un 100% o más mientras reduce simultáneamente el uso de CPU y memoria.

Para bases de datos basadas en SQL:

1. No aprovechar los ÍNDICES AGRUPADOS ni elegir las columnas incorrectas para AGRUPAR.
2. No usar un tipo de datos SERIAL (número automático) como CLAVE PRIMARIA para unirse a una CLAVE EXTRANJERA (INT) en una relación de tabla padre / hijo.
3. No ACTUALIZAR ESTADÍSTICAS en una tabla cuando se han INSERTADO o BORRADO muchos registros.
4. No reorganizar (es decir, descargar, dejar caer, volver a crear, cargar y volver a indexar) tablas cuando se han insertado o eliminado muchas filas (algunos motores mantienen físicamente las filas eliminadas en una tabla con un indicador de eliminación).
5. No aprovechar FRAGMENTO DE EXPRESIÓN (si se admite) 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 adecuado.
8. No agregar nuevas columnas al final de la tabla.
9. No se crean índices adecuados para admitir consultas de uso frecuente.
10. creando índices en columnas con pocos valores posibles y creando índices innecesarios.
    ... más para agregar.

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

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

• Miedo a usar procesos almacenados o miedo a usar consultas ORM donde sea que sea más eficiente / apropiado de usar.

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

No está haciendo el nivel correcto de normalización . Desea asegurarse de que los datos no estén duplicados y que los esté dividiendo en diferentes según sea necesario. También debe asegurarse de no seguir demasiado la normalización, ya que eso perjudicará el rendimiento.

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

• Descartar un ORM como Hibernate, por razones como "es demasiado mágico" o "no está en mi base de datos".
• Confiar demasiado en un ORM como Hibernate e intentar calzarlo donde no sea apropiado.

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

Ejemplo:

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

en vez de

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

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

2 - No agregar restricciones de verificación para garantizar la validez de los datos. El optimizador de consultas puede usar restricciones, y REALMENTE ayudan a garantizar que pueda confiar en sus invariantes. 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 desorden cuando te muerde la integridad de datos perdida en futuras evoluciones.

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

4 - no tanto sobre la base de datos per se sino realmente molesto. No me 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 tu compañero programador pueda leer.

Esto se ha dicho antes, pero: índices, índices, índices . He visto muchos casos de aplicaciones web empresariales de bajo rendimiento que se corrigieron simplemente haciendo un pequeño perfil (para ver qué tablas se golpearon mucho) y luego agregando un índice en esas tablas. Esto ni siquiera requiere mucho conocimiento de escritura SQL, y la recompensa es enorme.

Evite la duplicación de datos como la peste. Algunas personas defienden que una pequeña duplicación no perjudicará y mejorará el rendimiento. Oye, no digo que tengas que torturar tu esquema en la Tercera Forma Normal, hasta que sea tan abstracto que ni siquiera los DBA sepan lo que está sucediendo. Solo comprenda que siempre que duplique un conjunto de nombres, códigos postales o códigos de envío, las copias eventualmente no se sincronizarán entre sí. Pasará. Y luego te patearás mientras ejecutas el script de mantenimiento semanal.

Y por último: use una convención de nomenclatura clara, coherente e intuitiva. De la misma manera que un código bien escrito debería ser legible, un buen esquema o consulta SQL debería ser legible y prácticamente decirle lo que está haciendo, incluso sin comentarios. Te agradecerás en seis meses, cuando tengas que realizar tareas de mantenimiento en las mesas. "SELECT account_number, billing_date FROM national_accounts"es infinitamente más fácil trabajar con "SELECT ACCNTNBR, BILLDAT FROM NTNLACCTS".

¡No ejecuta 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 desarrollen las aplicaciones. El resultado final es a menudo un desastre e ineficiente y difícil de limpiar o simplificar más adelante.

a) Codificar valores de consulta en la 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 los dos.

No prestar suficiente atención a la gestión de conexiones de bases de datos en su aplicación. Luego descubre que la aplicación, la computadora, 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. Pensar que su proyecto no requiere un DBA porque todo eso es fácil / trivial.

3. No discernir adecuadamente 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 sin formato en su código.

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

No comprender el modelo de concurrencia de bases de datos y cómo esto afecta el desarrollo. Es fácil agregar índices y ajustar consultas después del hecho. Sin embargo, las aplicaciones diseñadas sin la debida consideración de los puntos críticos, la contención de recursos y el funcionamiento correcto (¡suponiendo que lo que acaba de leer sigue siendo válido!) Pueden requerir cambios significativos dentro de la base de datos y el nivel de aplicación para corregirlos más adelante.

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

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

Específicamente:

1. ¿Sabes qué es un índice agrupado? ¿Lo pensaste cuando diseñaste tu esquema?

2. ¿Sabes cómo usar los índices correctamente? ¿Cómo reutilizar un índice? ¿Sabes qué es un índice de cobertura?

3. Muy bien, tienes índices. ¿Qué tan grande es 1 fila en su índice? ¿Qué tan grande será el índice cuando tenga muchos datos? ¿Encajará eso fácilmente en la memoria? Si no es así, es inútil como índice.

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

5. ¿Entiendes el caché de consultas? ¿Sabes qué hace que una consulta no se pueda almacenar en caché?

6. ¿Estás usando MyISAM? Si NECESITA la búsqueda de texto completo, MyISAM es una mierda de todos modos. Usa la esfinge. Luego cambia a Inno.

1. Usando un ORM para hacer actualizaciones masivas
2. Seleccionar más datos de los necesarios. Nuevamente, generalmente se hace cuando se usa un ORM
3. Disparando sqls en un bucle.
4. No tener buenos datos de prueba y notar una degradación del rendimiento solo en datos en vivo.