database - son - relaciones base de datos
¿Qué deben saber todos los desarrolladores sobre las bases de datos? (30)
Nos guste o no, muchos, si no la mayoría de nosotros, los desarrolladores trabajamos regularmente con bases de datos o quizás tengamos que trabajar con uno algún día. Y considerando la cantidad de uso indebido y abuso en la naturaleza, y el volumen de preguntas relacionadas con la base de datos que surgen todos los días, es justo decir que hay ciertos conceptos que los desarrolladores deben saber, incluso si no diseñan o trabajan con ellos. bases de datos de hoy. Asi que:
¿Cuáles son los conceptos importantes que los desarrolladores y otros profesionales del software deben conocer sobre las bases de datos?
Pautas para las respuestas:
Mantenga su lista corta.
Un concepto por respuesta es el mejor.
Ser especifico
El "modelado de datos" puede ser una habilidad importante, pero ¿qué significa eso exactamente?
Explique su razonamiento.
¿Por qué es importante tu concepto? No se limite a decir "usar índices". No caigas en las "mejores prácticas". Convence a tu audiencia para que vaya aprendiendo más.
Upvote respuestas con las que está de acuerdo.
Lee las respuestas de otras personas primero. Una respuesta de alto rango es una declaración más efectiva que dos de bajo rango. Si tiene más que agregar, agregue un comentario o haga referencia al original.
No descargues algo solo porque no se aplica a ti personalmente.
Todos trabajamos en diferentes dominios. El objetivo aquí es proporcionar orientación a los principiantes de la base de datos para obtener una comprensión bien fundada y completa del diseño de la base de datos y el desarrollo impulsado por la base de datos, no para competir por el título de más importante.
Cómo funcionan los índices
Probablemente no sea el más importante, pero seguramente el tema más subestimado.
El problema con la indexación es que los tutoriales de SQL generalmente no los mencionan en absoluto y que todos los ejemplos de juguetes funcionan sin ningún índice.
Incluso los desarrolladores más experimentados pueden escribir SQL bastante bueno (y complejo) sin saber más sobre los índices que " Un índice hace que la consulta sea rápida ".
Eso es porque las bases de datos SQL hacen un muy buen trabajo trabajando como caja negra:
Dime que necesitas (dame SQL), me encargaré de ello.
Y eso funciona perfectamente para recuperar los resultados correctos. El autor del SQL no necesita saber qué está haciendo el sistema detrás de la escena, hasta que todo se vuelva tan débil ...
Ahí es cuando la indexación se convierte en un tema. Pero eso suele ser muy tarde y alguien (¿alguna compañía?) Ya está sufriendo un problema real.
Por eso creo que la indexación es el tema número 1 que no debe olvidarse al trabajar con bases de datos . Desafortunadamente, es muy fácil olvidarlo.
Renuncia
Los argumentos están tomados del preface de mi libro electrónico gratuito " Use The Index, Luke ". Paso mucho de mi tiempo explicando cómo funcionan los índices y cómo usarlos correctamente.
Indexación básica
Siempre me sorprende ver una tabla o una base de datos completa sin índices, o índices arbitrarios / inútiles. Incluso si no estás diseñando la base de datos y solo tienes que escribir algunas consultas, es vital entender, como mínimo:
- Lo que está indexado en su base de datos y lo que no está:
- La diferencia entre los tipos de análisis, cómo se eligen y cómo la forma en que escribe una consulta puede influir en esa elección;
- El concepto de cobertura (por qué no debería simplemente escribir
SELECT *); - La diferencia entre un índice agrupado y no agrupado;
- Por qué los índices más / más grandes no son necesariamente mejores;
- Por qué debería intentar evitar el ajuste de columnas de filtro en funciones.
Los diseñadores también deben tener en cuenta los patrones de índice comunes, por ejemplo:
- El antipatrón de acceso (indexando cada columna, una por una)
- El anti-patrón Catch-All (un índice masivo en todas o la mayoría de las columnas, aparentemente creado bajo la impresión errónea de que aceleraría cada consulta concebible que involucre cualquiera de esas columnas).
La calidad de la indexación de una base de datos, y si se aprovecha o no con las consultas que escribe, representa, con mucho, la parte más significativa del rendimiento. 9 de cada 10 preguntas publicadas en SO y en otros foros quejándose de un rendimiento deficiente se deben invariablemente a una mala indexación o una expresión no compilable.
Normalización
Siempre me deprime ver a alguien que lucha por escribir una consulta excesivamente complicada que hubiera sido completamente sencilla con un diseño normalizado ("Mostrar las ventas totales por región").
Si entiendes esto desde el principio y diseñas en consecuencia, te ahorrarás mucho dolor más adelante. Es fácil desnormalizar el rendimiento después de haberte normalizado; No es tan fácil normalizar una base de datos que no fue diseñada de esa manera desde el principio.
Como mínimo, debe saber qué es 3NF y cómo llegar allí. Con la mayoría de las bases de datos transaccionales, este es un muy buen equilibrio entre hacer que las consultas sean fáciles de escribir y mantener un buen rendimiento.
Aparte de la sintaxis y las opciones conceptuales que emplean (como las combinaciones, los desencadenantes y los procedimientos almacenados), una cosa que será fundamental para todos los desarrolladores que emplean una base de datos es esto:
Sepa cómo su motor realizará la consulta que está escribiendo con especificidad.
La razón por la que creo que esto es tan importante es simplemente la estabilidad de la producción. Debería saber cómo funciona su código para no detener toda la ejecución en su hilo mientras espera que se complete una función larga, así que, ¿por qué no querría saber cómo afectará su consulta a la base de datos, su programa y quizás incluso? ¿el servidor?
Esto es realmente algo que ha golpeado a mi equipo de I + D más veces que faltas de punto y coma o algo similar. La presunción es que la consulta se ejecutará rápidamente porque lo hace en su sistema de desarrollo con solo unos pocos miles de filas en las tablas. Incluso si la base de datos de producción es del mismo tamaño, es muy probable que se use mucho más y, por lo tanto, sufra otras restricciones, como que varios usuarios accedan a ella al mismo tiempo, o que algo vaya mal en otra consulta, lo que retrasa El resultado de esta consulta.
Incluso las cosas simples como la forma en que las uniones afectan el rendimiento de una consulta son invaluables en la producción. Hay muchas características de muchos motores de base de datos que facilitan las cosas conceptualmente, pero pueden introducir errores en el rendimiento si no se lo piensa con claridad.
Conozca el proceso de ejecución del motor de su base de datos y planifíquelo.
Buena pregunta. Los siguientes son algunos pensamientos en ningún orden en particular:
La normalización, al menos a la segunda forma normal, es esencial.
La integridad referencial también es esencial, con las consideraciones correctas de eliminación y actualización en cascada.
Buen y correcto uso de las restricciones de verificación. Deja que la base de datos haga el mayor trabajo posible.
No dispersar la lógica de negocios en la base de datos y el código de nivel medio. Elija uno u otro, preferiblemente en el código de nivel medio.
Decida un enfoque coherente para las claves primarias y las claves agrupadas.
No sobre el índice. Elija sus índices con prudencia.
Nombramiento consistente de tablas y columnas. Elige un estándar y apégate a él.
Limite el número de columnas en la base de datos que aceptarán valores nulos.
No te dejes llevar por los disparadores. Tienen su uso pero pueden complicar las cosas a toda prisa.
Ten cuidado con los UDFs. Son geniales, pero pueden causar problemas de rendimiento cuando no se sabe con qué frecuencia pueden llamarse en una consulta.
Obtenga el libro de Celko sobre el diseño de bases de datos. El hombre es arrogante pero sabe lo que hace.
Considere la Denormalization como un posible ángel, no el demonio, y también considere las bases de datos NoSQL como una alternativa a las bases de datos relacionales.
Además, creo que el modelo Entidad-Relación es una necesidad para todos los desarrolladores, incluso si no diseña bases de datos. Te permitirá entender completamente de qué se trata tu base de datos.
Creo que cada desarrollador debe entender que las bases de datos requieren un paradigma diferente .
Al escribir una consulta para obtener sus datos, se necesita un enfoque basado en conjuntos. Muchas personas con antecedentes interactivos luchan con esto. Y, sin embargo, cuando lo aceptan, pueden lograr resultados mucho mejores, aunque la solución no sea la que se presentó por primera vez en sus mentes centradas en la iteración.
Creo que muchos de los detalles técnicos se han cubierto aquí y no quiero agregarlos. Lo único que quiero decir es más social que técnico, no caiga en la trampa de "DBA sabiendo lo mejor" como desarrollador de aplicaciones.
Si tiene problemas de rendimiento con la consulta, tome posesión del problema también. Haga su propia investigación y pida a los DBA que expliquen qué está sucediendo y cómo sus soluciones están abordando el problema.
Haz tus propias sugerencias también después de que hayas hecho la investigación. Es decir, trato de encontrar una solución cooperativa al problema en lugar de dejar los problemas de la base de datos a los DBA.
De mi experiencia con bases de datos relacionales, cada desarrollador debe saber:
- Los diferentes tipos de datos :
El uso del tipo correcto para el trabajo correcto hará que su diseño de base de datos sea más robusto, sus consultas más rápidas y su vida más fácil.
- Aprender sobre 1xM y MxM :
Este es el pan y la mantequilla para las bases de datos relacionales. Debe comprender las relaciones de uno a muchos y de muchos a muchos y aplicar cuando sea apropiado.
- El principio " K.I.S.S. " se aplica también a la DB :
La simplicidad siempre funciona mejor. Siempre que haya estudiado cómo funciona el DB, evitará una complejidad innecesaria que dará lugar a problemas de mantenimiento y velocidad.
- Índices :
No es suficiente si sabes lo que son. Necesitas entender cuándo usarlos y cuándo no.
además:
- El álgebra de Boole es tu amigo.
- Imágenes: No los almacene en el DB. No preguntes por qué.
- Prueba BORRAR con SELECCIONAR
Diseño de bases de datos evolutivas. http://martinfowler.com/articles/evodb.html
Estas metodologías ágiles hacen que el proceso de cambio de base de datos sea manejable, predecible y comprobable.
Los desarrolladores deben saber qué se necesita para refactorizar una base de datos de producción en términos de control de versiones, integración continua y pruebas automatizadas.
El proceso de diseño de base de datos evolutivo tiene aspectos administrativos, por ejemplo, una columna se debe eliminar después de un período de tiempo de vida en todas las bases de datos de este código base.
Al menos saber, que existen conceptos y metodologías de Refactorización de Bases de Datos. http://www.agiledata.org/essays/databaseRefactoringCatalog.html
La clasificación y la descripción del proceso también permiten implementar herramientas para estas refactorizaciones.
El orden de las columnas en un índice no único es importante.
La primera columna debe ser la columna que tenga la mayor variabilidad en su contenido (es decir, la cardinalidad).
Esto es para ayudar a la capacidad de SQL Server para crear estadísticas útiles sobre cómo usar el índice en tiempo de ejecución.
Excelente pregunta. Veamos, primero nadie debería considerar consultar una base de datos que no comprende a fondo las uniones. Es como conducir un automóvil sin saber dónde están el volante y los frenos. También necesita saber los tipos de datos y cómo elegir el mejor.
Otra cosa que los desarrolladores deberían entender es que hay tres cosas que debes tener en cuenta al diseñar una base de datos:
Integridad de los datos: si no se puede confiar en los datos, básicamente no tiene datos, esto significa que no debe incluir la lógica requerida en la aplicación ya que muchas otras fuentes pueden tocar la base de datos. Las restricciones, las claves externas y, a veces, los disparadores son necesarios para la integridad de los datos. No dejes de usarlos porque no te gustan o no quieres que te molesten en entenderlos.
Rendimiento: es muy difícil refactorizar una base de datos de bajo rendimiento y el rendimiento debe considerarse desde el principio. Hay muchas maneras de hacer la misma consulta y se sabe que algunas son más rápidas casi siempre, es miope no aprender y usar estas formas. Lea algunos libros sobre ajuste de rendimiento antes de diseñar consultas o estructuras de base de datos.
Seguridad: estos datos son el elemento vital de su empresa y, con frecuencia, también contienen información personal que puede ser robada. Aprenda a proteger sus datos de ataques de inyección SQL y fraude y robo de identidad.
Al consultar una base de datos, es fácil obtener la respuesta incorrecta. Asegúrese de entender su modelo de datos a fondo. Recuerde que a menudo las decisiones reales se toman en función de los datos que devuelve su consulta. Cuando está mal, se toman las decisiones comerciales equivocadas. Puedes matar a una empresa por malas consultas o perder un gran cliente. Los datos tienen significado, los desarrolladores a menudo parecen olvidar eso.
Los datos casi nunca desaparecen, piense en términos de almacenar datos a lo largo del tiempo en lugar de cómo obtenerlos hoy. Esa base de datos que funcionó bien cuando tenía cien mil registros, puede que no sea tan agradable en diez años. Las aplicaciones rara vez duran tanto como los datos. Esta es una razón por la cual el diseño para el rendimiento es crítico.
Su base de datos probablemente necesitará campos que la aplicación no necesita ver. Cosas como GUIDs para replicación, campos de fecha de inserción. Es posible que también necesite almacenar el historial de cambios y quién los hizo cuándo y poder restaurar los cambios incorrectos de este almacén. Piense en cómo piensa hacer esto antes de venir. Pregunte a un sitio web cómo solucionar el problema en el que olvidó poner una cláusula where en una actualización y actualizó toda la tabla.
Nunca se desarrolle en una versión más nueva de una base de datos que la versión de producción. Nunca, nunca, nunca se desarrolle directamente contra una base de datos de producción.
Si no tiene un administrador de base de datos, asegúrese de que alguien esté haciendo copias de seguridad y sepa cómo restaurarlas y que haya probado restaurarlas.
El código de la base de datos es el código, no hay excusa para no mantenerlo en el control de la fuente como lo hace el resto de su código.
Lo primero que deben saber los desarrolladores sobre las bases de datos es esto: ¿para qué sirven las bases de datos ? Ni cómo funcionan, ni cómo crea uno, ni cómo se escribe el código para recuperar o actualizar los datos en una base de datos. ¿Pero para qué sirven?
Desafortunadamente, la respuesta a esta pregunta es un objetivo en movimiento. En el heydey de las bases de datos, desde la década de 1970 hasta principios de la década de 1990, las bases de datos eran para compartir datos. Si estaba usando una base de datos y no estaba compartiendo datos, o bien estaba involucrado en un proyecto académico o desperdició recursos, incluyéndose a usted. La creación de una base de datos y la domesticación de un DBMS eran tareas tan monumentales que el reembolso, en términos de datos explotados varias veces, tenía que ser enorme para igualar la inversión.
En los últimos 15 años, las bases de datos se han utilizado para almacenar los datos persistentes asociados con una sola aplicación. La creación de una base de datos para MySQL , Access o SQL Server se ha vuelto tan rutinaria que las bases de datos se han convertido casi en una parte rutinaria de una aplicación ordinaria. A veces, esa misión limitada inicial se ve empujada hacia arriba por el avance de la misión, a medida que el valor real de los datos se hace evidente. Desafortunadamente, las bases de datos que fueron diseñadas con un solo propósito en mente a menudo fallan dramáticamente cuando comienzan a ser asumidas en un rol que es de gran alcance para toda la empresa.
La segunda cosa que los desarrolladores deben aprender sobre las bases de datos es la visión global del mundo centrada en los datos . La visión del mundo centrada en los datos es más diferente de la visión del mundo centrada en el proceso que cualquier otra cosa que la mayoría de los desarrolladores hayan aprendido. En comparación con esta brecha, la brecha entre la programación estructurada y la programación orientada a objetos es relativamente pequeña.
La tercera cosa que los desarrolladores deben aprender, al menos en una descripción general, es el modelado de datos, incluido el modelado conceptual de datos, el modelado lógico de datos y el modelado de datos físicos.
El modelado conceptual de datos es realmente un análisis de requerimientos desde un punto de vista centrado en los datos.
El modelado lógico de datos es generalmente la aplicación de un modelo de datos específico a los requisitos descubiertos en el modelado conceptual de datos. El modelo relacional se usa mucho más que cualquier otro modelo específico, y los desarrolladores necesitan aprender el modelo relacional con seguridad. Diseñar un modelo relacional poderoso y relevante para un requisito no trivial no es una tarea trivial. No puede construir buenas tablas SQL si no entiende el modelo relacional.
El modelado físico de datos generalmente es específico de DBMS y no necesita aprenderse en detalle, a menos que el desarrollador sea también el creador de la base de datos o el DBA. Lo que los desarrolladores deben entender es hasta qué punto se puede separar el diseño físico de la base de datos del diseño lógico de la base de datos, y hasta qué punto se puede lograr la creación de una base de datos de alta velocidad con solo modificar el diseño físico.
Lo siguiente que deben aprender los desarrolladores es que si bien la velocidad (rendimiento) es importante, otras medidas de bondad de diseño son aún más importantes , como la capacidad de revisar y ampliar el alcance de la base de datos en el futuro o la simplicidad de la programación.
Finalmente, cualquier persona que se mete con las bases de datos debe comprender que el valor de los datos a menudo supera al sistema que los capturó .
¡Uf!
Me gustaría que todos, tanto los administradores de bases de datos como los desarrolladores / diseñadores / arquitectos, comprendan mejor cómo modelar correctamente un dominio de negocios y cómo mapear / traducir ese modelo de dominio de negocios en un modelo lógico de base de datos normalizado, un modelo físico optimizado y un modelo de clase apropiado orientado a objetos, cada uno de los cuales es (puede ser) diferente, por varias razones, y comprende cuándo, por qué y cómo son (o deberían ser) diferentes entre sí.
Nunca inserte datos con la codificación de texto incorrecta.
Una vez que su base de datos se contamine con varias codificaciones, lo mejor que puede hacer es aplicar una combinación amable de heurística y trabajo manual.
Para un desarrollador profesional de nivel intermedio que usa mucho las bases de datos (escribir / mantener consultas a diario o casi a diario), creo que la expectativa debería ser la misma que en cualquier otro campo: usted escribió una en la universidad .
Cada geek de C ++ escribió una clase de cuerdas en la universidad. Cada friki de los gráficos escribió un raytracer en la universidad. Cada geek de la web escribió sitios web interactivos (generalmente antes de que tuviéramos "marcos web") en la universidad. Cada nerd de hardware (e incluso nerds de software) construyeron una CPU en la universidad. Todos los médicos diseccionaron un cadáver entero en la universidad, incluso si solo me tomaría la presión arterial y me diría que mi colesterol está demasiado alto hoy. ¿Por qué las bases de datos serían diferentes?
Desafortunadamente, hoy parecen diferentes, por alguna razón. La gente quiere que los programadores .NET sepan cómo funcionan las cadenas en C , pero los aspectos internos de su RDBMS no deberían preocuparle demasiado .
Es virtualmente imposible obtener el mismo nivel de comprensión con solo leer sobre ellos, o incluso trabajar hacia abajo desde la parte superior. Pero si empiezas desde abajo y entiendes cada pieza, entonces es relativamente fácil descubrir los detalles de tu base de datos. Incluso las cosas que muchos geeks de bases de datos no parecen asimilar, como cuándo usar una base de datos no relacional.
Tal vez sea un poco estricto, especialmente si no estudiaste ciencias de la computación en la universidad. Lo suavizaré un poco: puedes escribir uno hoy , completamente, desde cero. No me importa si conoce los detalles específicos de cómo funciona el optimizador de consultas PostgreSQL, pero si sabe lo suficiente como para escribir uno, probablemente no sea muy diferente de lo que hicieron. Y sabes, realmente no es tan difícil escribir uno básico.
Primero, los desarrolladores deben comprender que hay algo que saber sobre las bases de datos. No son solo dispositivos mágicos donde se coloca el SQL y se eliminan los conjuntos de resultados, sino que se trata de piezas de software muy complicadas con su propia lógica y peculiaridades.
En segundo lugar, que hay diferentes configuraciones de base de datos para diferentes propósitos. No desea que un desarrollador realice informes históricos de una base de datos transaccional en línea si hay un almacén de datos disponible.
En tercer lugar, los desarrolladores deben comprender el SQL básico, incluidas las combinaciones.
Más allá de esto, depende de qué tan cerca estén involucrados los desarrolladores. He trabajado en trabajos en los que era desarrollador y DBA de facto, donde los DBA estaban justo al final del pasillo y donde los DBA están fuera de su propia área. (No me gusta el tercero). Suponiendo que los desarrolladores están involucrados en el diseño de la base de datos:
Necesitan entender la normalización básica, al menos las tres primeras formas normales. Cualquier cosa más allá de eso, consigue un DBA. Para aquellos con experiencia en salas de audiencias de Estados Unidos (y los programas de televisión aleatorios cuentan aquí), está la mnemotécnica "Depende de la clave, de toda la clave, y nada más que de la clave, así que ayude a Codd".
Necesitan tener una pista sobre los índices, por lo que quiero decir que deberían tener una idea de qué índices necesitan y cómo es probable que afecten el rendimiento. Esto significa no tener índices inútiles, pero no tener miedo de agregarlos para ayudar a las consultas. Cualquier cosa más (como el saldo) debe dejarse para el DBA.
Deben comprender la necesidad de integridad de los datos y ser capaces de señalar dónde están verificando los datos y qué están haciendo si encuentran problemas. Esto no tiene que estar en la base de datos (donde será difícil emitir un mensaje de error significativo para el usuario), pero tiene que estar en algún lugar.
Deben tener el conocimiento básico de cómo obtener un plan y cómo leerlo en general (al menos lo suficiente para saber si los algoritmos son eficientes o no).
Deben saber vagamente qué es un activador, qué es una vista y que es posible particionar partes de bases de datos. No necesitan ningún tipo de detalles, pero deben saber preguntar al DBA sobre estas cosas.
Por supuesto, deben saber no inmiscuirse con los datos de producción, el código de producción o algo así, y deben saber que todo el código fuente se incluye en un VCS.
Sin duda, he olvidado algo, pero el desarrollador promedio no necesita ser un DBA, siempre que haya un DBA real a la mano.
Simple respeto
- No es solo un repositorio
- Probablemente no sepa mejor que el proveedor o los DBA
- No lo apoyarás a las 3 am con altos directivos gritándote
Sobre el siguiente comentario a la respuesta de Walter M.:
"¡Muy bien escrito! Y la perspectiva histórica es genial para las personas que no estaban haciendo el trabajo de base de datos en ese momento (es decir, yo)".
La perspectiva histórica es, en cierto sentido, absolutamente crucial. "Los que olvidan la historia, están condenados a repetirla". Cfr XML repitiendo los errores jerárquicos del pasado, gráficos de bases de datos repitiendo los errores de la red del pasado, sistemas OO que imponen el modelo jerárquico a los usuarios, mientras que todo el mundo con solo una décima parte del cerebro debería saber que el modelo jerárquico no es adecuado para el público en general. Representación del propósito del mundo real, etcétera, etcétera.
En cuanto a la pregunta en sí:
Todo desarrollador de bases de datos debe saber que "Relacional" no es igual a "SQL". Entonces entenderían por qué los proveedores de DBMS les están decepcionando tan abismalmente, y por qué deberían decirles a esos mismos proveedores que creen mejores cosas (por ejemplo, DBMS que sean verdaderamente relacionales) si quieren seguir chupando cantidades hilarantes de dinero fuera de sus clientes para tal software de mierda).
Y todo desarrollador de bases de datos debe saber todo sobre el álgebra relacional. Entonces ya no quedaría un solo desarrollador que tuviera que publicar estas preguntas estúpidas de "No sé cómo hacer mi trabajo y quiero que alguien más lo haga por mí" en .
Solo quiero señalar una observación: es que parece que la mayoría de las respuestas asumen que la base de datos es intercambiable con las bases de datos relacionales. También hay bases de datos de objetos, bases de datos de archivos planos. Es importante evaluar las necesidades del proyecto de software en cuestión. Desde la perspectiva del programador, la decisión de la base de datos puede retrasarse hasta más tarde. El modelado de datos, por otro lado, se puede lograr desde el principio y llevar a mucho éxito.
Creo que el modelado de datos es un componente clave y es un concepto relativamente antiguo, pero es uno que ha sido olvidado por muchos en la industria del software. El modelado de datos, especialmente el modelado conceptual, puede revelar el comportamiento funcional de un sistema y se puede confiar en él como una hoja de ruta para el desarrollo.
Por otro lado, el tipo de base de datos requerida se puede determinar en función de muchos factores diferentes para incluir el entorno, el volumen de usuarios y el hardware local disponible, como el espacio del disco duro.
Todo desarrollador debe saber que esto es falso: "Perfilar una operación de base de datos es completamente diferente del código de perfilado".
Hay un claro Big-O en el sentido tradicional. Cuando haces un EXPLAIN PLAN (o el equivalente) estás viendo el algoritmo. Algunos algoritmos incluyen bucles anidados y son O ( n ^ 2). Otros algoritmos implican búsquedas de árbol B y son O ( n log n ).
Esto es muy, muy serio. Es fundamental para entender por qué los índices son importantes. Es fundamental para comprender los intercambios de velocidad-normalización-desnormalización. Es fundamental para comprender por qué un almacén de datos utiliza un esquema en estrella que no está normalizado para las actualizaciones transaccionales.
Si no está seguro del algoritmo utilizado, haga lo siguiente. Detener. Explique el plan de ejecución de la consulta. Ajuste los índices en consecuencia.
Además, el corolario: Más índices no son mejores.
A veces, un índice centrado en una operación ralentizará otras operaciones. Dependiendo de la proporción de las dos operaciones, agregar un índice puede tener buenos efectos, no tener un impacto general o ser perjudicial para el rendimiento general.
Yo diría fuertes habilidades básicas de SQL. Hasta ahora he visto muchos desarrolladores que saben un poco sobre bases de datos, pero siempre están pidiendo consejos sobre cómo formular una consulta bastante simple. Las consultas no siempre son tan fáciles y sencillas. Debe utilizar varias combinaciones (interna, izquierda, etc.) al consultar una base de datos bien normalizada.
¡Entiende las herramientas que usas para programar la base de datos!
Perdí tanto tiempo tratando de entender por qué mi código estaba fallando misteriosamente.
Si está utilizando .NET, por ejemplo, necesita saber cómo usar correctamente los objetos en el System.Data.SqlClientespacio de nombres. Debe saber cómo administrar sus SqlConnectionobjetos para asegurarse de que estén abiertos, cerrados y, cuando sea necesario, desechados correctamente.
Debe saber que cuando usa una SqlDataReader, es necesario cerrarla por separado de su SqlConnection. Debe comprender cómo mantener las conexiones abiertas cuando sea apropiado y cómo minimizar el número de visitas a la base de datos (porque son relativamente caros en términos de tiempo de cálculo).
Compatibilidad RDBMS
Mira si es necesario para ejecutar la aplicación en más de un RDBMS. Si es así, podría ser necesario:
- evitar las extensiones de RDBMS SQL
- eliminar los desencadenantes y almacenar procedimientos
- seguir estrictos estándares de SQL
- convertir tipos de datos de campo
- cambiar los niveles de aislamiento de transacción
De lo contrario, estas preguntas deberían tratarse por separado y se desarrollarían diferentes versiones (o configuraciones) de la aplicación.
El problema de desajuste de impedancia, y conocer las deficiencias comunes u ORMs.
No dependa del orden de las filas devueltas por una consulta SQL.
Para algunos proyectos, y modelo orientado a objetos es mejor.
Para otros proyectos, un modelo relacional es mejor.
- Habilidades básicas de SQL.
- Indexación.
- Tratar con diferentes encarnaciones de DATE / TIME / TIMESTAMP.
- Documentación del controlador JDBC para la plataforma que está utilizando.
- Tratar con los tipos de datos binarios ( CLOB , BLOB , etc.)