¿Qué debe saber todo desarrollador acerca de las bases de datos? [cerrado]


206

Nos guste o no, muchos, si no la mayoría de nosotros, los desarrolladores trabajamos regularmente con bases de datos o algún día tendremos que trabajar con una. Y teniendo en cuenta la cantidad de mal uso 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 ni trabajan con ellos. bases de datos de hoy. Entonces:



¿Cuáles son los conceptos importantes que los desarrolladores y otros profesionales del software deben saber sobre las bases de datos?


Pautas para las respuestas:


Mantenga su lista corta.
Un concepto por respuesta es el mejor.

Se específico .
El "modelado de datos" puede ser una habilidad importante , pero ¿qué significa eso exactamente?

Explica tu razonamiento.
¿Por qué es importante tu concepto? No solo diga "usar índices". No caigas en las "mejores prácticas". Convence a tu audiencia para que aprenda más.

Vota respuestas con las que estás de acuerdo.
Lea primero las respuestas de otras personas. 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 rechaces algo solo porque no se aplica a ti personalmente.
Todos trabajamos en diferentes dominios. El objetivo aquí es proporcionar direcció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.


15
¿Por qué votar para cerrar esto? Es una comunidad Wikia y, por lo tanto, apropiada.
David

55
Voy a votar para reabrir si se cierra ... También me gustaría ver una lista de esas cosas que los DBA deberían (pero no saben) sobre OOP y el diseño de aplicaciones / software de sistemas ..
Charles Bretana

77
@gnovice: La palabra "subjetivo" en ese contexto se refiere a preguntas que son completamente una cuestión de opinión. "¿Qué opinas del libro de Joe Celko?" Esa es una pregunta subjetiva. Esta pregunta está solicitando información objetiva, simplemente sucede que no hay una respuesta "correcta" única. Creo que es importante dar un paso atrás y preguntar, "¿esto es una broma inactiva, o es útil para algunos desarrolladores?" Mis dos centavos de todos modos, no es como si estuviera ganando puntos de representante por esto. :-)
Aaronaught

66
Personalmente, odio estas preguntas. Casi siempre equivalen a montones de opiniones personales, ligeras sobre información utilizable y pesadas sobre declaraciones subjetivas. Pero no estoy dispuesto a cerrarlo solo por esa razón; que podría estar a mitad de camino decente, Aaron, si establece algunas pautas para respuestas: un solo tema respuestas (lo que se debe saber y por qué se debe saber que no hay), duplicados, arriba-voto lo que está de acuerdo con ... y la mayoría lo que es importante, mueva sus propias opiniones a respuestas que lo demuestren Tal como está, esto se lee como una publicación de blog o una discusión en un foro, ninguno de los cuales tiene ningún negocio en SO.
Shog9

44
Esto me parece bastante interesante: "Es un Wiki de la comunidad y, por lo tanto, apropiado". ¿Cómo puede un CW hacerlo apropiado? Ya sea una pregunta es apropiado o no, y creo que esta pregunta es modo subjetivo a ser útil si alguien está buscando una respuesta. Puede ser interesante, pero esa no es la única característica que debe tener una pregunta.
Georg Schölly

Respuestas:


106

Lo primero que los desarrolladores deben saber sobre las bases de datos es esto: ¿para qué sirven las bases de datos ? No cómo funcionan, ni cómo construye uno, ni cómo escribe código para recuperar o actualizar los datos en una base de datos. ¿Pero para qué son?

Desafortunadamente, la respuesta a este es un objetivo en movimiento. En el apogeo de las bases de datos, desde los años setenta hasta principios de los noventa, las bases de datos eran para compartir datos. Si estaba utilizando una base de datos y no compartía datos, estaba involucrado en un proyecto académico o estaba desperdiciando recursos, incluido usted mismo. Configurar una base de datos y domesticar un DBMS fueron tareas tan monumentales que la recuperación de la inversión, en términos de datos explotados varias veces, tuvo 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. Crear una base de datos para MySQL , Access o SQL Server 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 arrastre 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 empujadas a un rol que abarca toda la empresa y es de misión crítica.

La segunda cosa que los desarrolladores necesitan aprender sobre las bases de datos es la vista completa 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 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.

Lo tercero que los desarrolladores deben aprender, al menos en una descripción general, es el modelado de datos, que incluye el modelado conceptual de datos, el modelado de datos lógicos y el modelado de datos físicos.

El modelado conceptual de datos es realmente un análisis de requisitos 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 comprende el modelo relacional.

El modelado de datos físicos generalmente es específico de DBMS, y no necesita ser aprendido con mucho detalle, a menos que el desarrollador sea también el creador de la base de datos o el DBA. Lo que los desarrolladores deben comprender es la medida en que el diseño de la base de datos física se puede separar del diseño lógico de la base de datos, y la medida en que se puede producir una base de datos de alta velocidad simplemente modificando el diseño físico.

Lo siguiente que los desarrolladores deben aprender 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, cualquiera que se meta con las bases de datos debe comprender que el valor de los datos a menudo supera al sistema que los capturó .

¡Uf!


Muy bien escrito! Y la perspectiva histórica es excelente para las personas que no estaban trabajando en bases de datos en ese momento (es decir, yo).
Aaronaught

66
Bien escrito Y creo que su último punto es ignorado con demasiada frecuencia por las personas que intentan "simplemente hacerlo".
DaveE

1
Hay una conexión entre lo que escribí y temas como Explicar plan, indexación y normalización de datos. Me encantaría discutir esa conexión en mayor profundidad en algún tipo de foro de discusión. SO no es tal foro.
Walter Mitty el

1
Si descubriste que este monstruo estaba leyendo, imagina lo que se siente al escribirlo. No me propuse escribir un ensayo. Una vez que comencé, parecía fluir. Quien haya agregado la negrita realmente ayudó a los lectores, OMI.
Walter Mitty

3
@Walter Usted proporcionó explicaciones para todos sus puntos, excepto para este: "La segunda cosa que los desarrolladores deben aprender sobre las bases de datos es la vista 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 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 ". ¿Podrías dar más detalles sobre esto? Usted dijo que la brecha es grande, pero creo que me gustaría entender realmente la vista centrada en datos y cómo se desacopla de la vista de proceso.
jedd.ahyoung

73

Buena pregunta. Los siguientes son algunos pensamientos en ningún orden en particular:

  1. La normalización, al menos hasta la segunda forma normal, es esencial.

  2. La integridad referencial también es esencial, con consideraciones apropiadas de eliminación y actualización en cascada.

  3. Uso correcto y adecuado de las restricciones de verificación. Deje que la base de datos haga el mayor trabajo posible.

  4. No disperse la lógica de negocios tanto en la base de datos como en el código de nivel medio. Elija uno u otro, preferiblemente en código de nivel medio.

  5. Decida un enfoque coherente para las claves primarias y las claves agrupadas.

  6. No sobrepasar el índice. Elige tus índices sabiamente.

  7. Nombres consistentes de tablas y columnas. Elija un estándar y manténgalo.

  8. Limite el número de columnas en la base de datos que aceptarán valores nulos.

  9. No te dejes llevar por los desencadenantes. Tienen su uso pero pueden complicar las cosas a toda prisa.

  10. Tenga cuidado con los UDF. Son geniales, pero pueden causar problemas de rendimiento cuando no se sabe con qué frecuencia se les puede llamar en una consulta.

  11. Obtenga el libro de Celko sobre diseño de bases de datos. El hombre es arrogante pero sabe lo que hace.


1
me interesa elaborar el tema 4. Este es un tema que siempre me ha intrigado.
Brad

9
@David: siempre he preferido ponerlo en ambos lugares. De esta forma, estará protegido contra errores y errores de usuario. No hay razón para hacer que cada columna sea anulable, o para permitir que valores fuera del rango 1-12 se inserten en una Monthcolumna. Las reglas comerciales complejas son, por supuesto, otra historia.
Aaronaught

1
@Brad: la mayoría de nuestras aplicaciones en el trabajo se realizaron mucho antes de que se establecieran procesos de programación sólidos. Por lo tanto, tenemos la lógica de negocios dispersa en todas partes. Algunos de ellos están en la interfaz de usuario, otros en el nivel medio y otros en la base de datos. Es un desastre. En mi opinión, la lógica de negocios pertenece al nivel medio.
Randy Minder

2
@David: si es una certeza absoluta de que las modificaciones de la base de datos solo se producirán en las aplicaciones, es posible que tenga razón. Sin embargo, esto es probablemente bastante raro. Dado que es probable que los usuarios ingresen datos directamente en la base de datos, también es una buena práctica incluir la validación en la base de datos. Además, algunos tipos de validación se realizan de manera más eficiente en la base de datos.
Randy Minder

1
El punto 8 es realmente importante. En general, es muy importante saber cómo obtener los tipos de columna correctos.
Chris Vest

22

Primero, los desarrolladores deben comprender que hay algo que saber sobre las bases de datos. No se trata solo de dispositivos mágicos en los que se ingresa el SQL y se obtienen conjuntos de resultados, sino más bien piezas de software muy complicadas con su propia lógica y peculiaridades.

Segundo, que hay diferentes configuraciones de bases de datos para diferentes propósitos. No desea que un desarrollador realice informes históricos desde 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 donde era desarrollador y DBA de facto, donde los DBA estaban justo al final del pasillo, y donde los DBA están apagados en 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 comprender la normalización básica, al menos las tres primeras formas normales. Cualquier cosa más allá de eso, obtén un DBA. Para aquellos con alguna experiencia en los tribunales de los EE. UU. (Y los programas de televisión aleatorios cuentan aquí), existe el mnemotécnico "Depende de la clave, la clave completa y nada más que la clave, así que ayúdelo Codd".

Necesitan tener una pista sobre los índices, con lo que quiero decir que deberían tener alguna 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 atender consultas. Cualquier cosa más (como el saldo) debe dejarse para el DBA.

Deben comprender la necesidad de la integridad de los datos y poder 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), sino que debe estar en algún lugar.

Deben tener los conocimientos básicos sobre cómo obtener un plan y cómo leerlo en general (al menos lo suficiente como para saber si los algoritmos son eficientes o no).

Deben saber vagamente qué es un disparador, qué es una vista y que es posible particionar partes de bases de datos. No necesitan ningún tipo de detalles, pero necesitan saber para preguntarle al DBA sobre estas cosas.

Por supuesto, deben saber no entrometerse con los datos de producción, o el código de producción, ni nada por el estilo, y deben saber que todo el código fuente va a un VCS.

Sin duda, he olvidado algo, pero el desarrollador promedio no necesita ser un DBA, siempre que haya un DBA real a mano.


19

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á diseñando la base de datos y solo tiene que escribir algunas consultas, es vital entender, como mínimo:

  • Qué está indexado en su base de datos y qué no:
  • La diferencia entre los tipos de escaneos, 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 envolver columnas de filtro en funciones.

Los diseñadores también deben conocer los antipatrones de índice comunes, por ejemplo:

  • El antipatrón de acceso (indexando cada columna, una por una)
  • El antipatró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 cualquier consulta concebible que implique cualquiera de esas columnas).

La calidad de la indexación de una base de datos, y si la aprovechas o no con las consultas que escribes, representa con mucho la parte más significativa del rendimiento. 9 de cada 10 preguntas publicadas en SO y en otros foros que se quejan de un rendimiento deficiente siempre se deben a una indexación deficiente o una expresión no sargable.


¿Puedes dar más detalles sobre la "cobertura"? Puedo ver por qué SELECT * no es un buen hábito para entrar, pero no sé el significado de "cobertura" y me pregunto si alude a otra razón para evitar SELECT *.
Edmund

1
@Edmund: un índice cubre una consulta si todos los campos de salida son parte del índice (ya sea como columnas indexadas o INCLUDEcolumnas en SQL Server). Si el único índice disponible para una consulta determinada no cubre, entonces todas las filas deben recuperarse, una por una, lo cual es una operación muy lenta, y la mayoría de las veces el optimizador de consultas decidirá que no vale la pena y realice un análisis completo de índice / tabla en su lugar. Es por eso que no escribe SELECT *: prácticamente garantiza que ningún índice cubrirá la consulta.
Aaronaught

¡Gracias! Aunque, como usuario de PostgreSQL, no necesito preocuparme por esas cosas (¿todavía?): Los índices no contienen información de visibilidad, por lo que las tuplas de tabla siempre necesitan ser escaneadas también. En general, sin embargo, parece un factor bastante importante.
Edmund

@Edmund: PostgreSQL puede no tener INCLUDEcolumnas (no puedo decirlo con certeza), pero eso no significa que no pueda poner columnas que desee cubrir en los datos de índice reales. Eso es lo que teníamos que hacer en los días de SQL Server 2000. La cobertura sigue siendo importante sin importar en qué DBMS se encuentre.
Aaronaught

16

Normalización

Siempre me deprime ver a alguien luchando por escribir una consulta excesivamente complicada que hubiera sido completamente sencilla con un diseño normalizado ("Muéstrame las ventas totales por región").

Si comprende esto desde el principio y diseña en consecuencia, se ahorrará mucho dolor más adelante. Es fácil desnormalizar el rendimiento después de que se haya 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 facilitar la escritura de consultas y mantener un buen rendimiento.


14

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 acerca de los índices que " Un índice agiliza la consulta ".

Esto se debe a que las bases de datos SQL hacen un muy buen trabajo trabajando como recuadro negro:

Dime qué necesitas (dame SQL), yo me encargaré.

Y eso funciona perfectamente para recuperar los resultados correctos. El autor del SQL no necesita saber qué está haciendo el sistema detrás de escena, hasta que todo se vuelve muuuuy lento ...

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.

Es por eso que 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.

Descargo de responsabilidad

Los argumentos están tomados del prefacio de mi libro electrónico gratuito " Use The Index, Luke ". Paso mucho tiempo explicando cómo funcionan los índices y cómo usarlos correctamente.


12

Solo quiero señalar una observación, es decir, parece que la mayoría de las respuestas suponen que la base de datos es intercambiable con 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 conducir a mucho éxito.

Creo que el modelado de datos es un componente clave y es un concepto relativamente antiguo, pero muchos lo han olvidado 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 del usuario y el hardware local disponible, como el espacio en el disco duro.


¿Te refieres a hacer diagramas de entidad-relación?
crosenblum

Sí ... ¿olvidé mencionar los ERD? :-)
FernandoZ

+1 ... Pero debes darte cuenta de que estás en SO: el hogar de los fontaneros que pasan sus días arreglando la falta de coincidencia de impedancia ORM para que todo lo que saben, comen y piensan no es solo relacional sino "SQL" :)
SyntaxT3rr0r


9

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 Big-O claro en el sentido tradicional. Cuando haces un EXPLAIN PLAN(o el equivalente) estás viendo el algoritmo. Algunos algoritmos involucran bucles anidados y son O ( n ^ 2). Otros algoritmos involucran búsquedas de árbol B y son O ( n log n ).

Esto es muy, muy serio. Es fundamental para entender por qué los índices importan. Es fundamental para comprender las compensaciones de velocidad-normalización-desnormalización. Es fundamental para entender por qué un almacén de datos utiliza un esquema en estrella que no está normalizado para las actualizaciones transaccionales.

Si no tiene claro el algoritmo que se utiliza, haga lo siguiente. Detener. Explicar el plan de ejecución de consultas. 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.


Tenía la sensación de que se tomaría el camino equivocado. Lo que quise decir con "tradicional" era que realmente no tienes ningún control sobre los algoritmos, solo la capacidad de influir sobre los que se usan. De todos modos, eliminé ese lenguaje ya que no quiero nada demasiado controvertido en la publicación principal.
Aaronaught

@Aaron: Usted no tiene control sobre los algoritmos. Para eso están los índices.
S.Lott

Hmm, ¿entonces puedes cambiar qué tipo de algoritmo de clasificación usa el DE? ¿Qué estructuras de datos se utilizan para el índice? Prefiero no discutir sobre este punto, por eso lo saqué, pero mantengo la idea básica de que tienes mucho menos control cuando trabajas con una base de datos en comparación con el código.
Aaronaught

@Aaron: Menos control no elimina la obligación de comprender realmente si la consulta es * O ** (* n ^ 2) o * O ** (* n log n ) o solo ** O ** (n). Menos control no elimina la obligación de comprender realmente lo que está sucediendo y descubrir cómo controlarlo.
S.Lott

@ S.Lott: Creo que estamos del mismo lado aquí, ya que estaba sugiriendo una mayor carga de creación de perfiles para las bases de datos: " Necesita saber ... [cómo] leer un plan de consulta". Pero mi edición parece haberse revertido, así que ... supongo que ahora pertenece a la comunidad.
Aaronaught

8

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 adoptan, pueden lograr resultados mucho mejores, a pesar de que la solución puede no ser la que se presentó por primera vez en sus mentes enfocadas de forma iterativa.


Por favor, aclare qué se entiende por enfoque "basado en conjuntos"
Vivian River

1
Que debería considerar los datos como conjuntos y considerar sus problemas como potencialmente resueltos mediante la aritmética de conjuntos, que implican funciones de clasificación donde sea necesario, subconsultas, agregados, etc. Muchos desarrolladores piensan en lo que debe hacerse en cada fila, que es el pensamiento iterativo.
Rob Farley

8

Excelente pregunta Veamos, primero nadie debería considerar consultar una base de datos que no comprende completamente las combinaciones. Es como conducir un automóvil sin saber dónde están el volante y los frenos. También necesita conocer los tipos de datos y cómo elegir el mejor.

Otra cosa que los desarrolladores deben entender es que hay tres cosas que debes tener en cuenta al diseñar una base de datos:

  1. Integridad de los datos: si no se puede confiar en los datos, esencialmente 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 activadores son necesarios para la integridad de los datos. No dejes de usarlos porque no te gustan o no quieres que te molesten en entenderlos.

  2. Rendimiento: es muy difícil refactorizar una base de datos de bajo rendimiento y el rendimiento debe considerarse desde el principio. Hay muchas formas 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 bases de datos.

  3. Seguridad: esta información es el elemento vital de su empresa, también contiene con frecuencia 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 comprender a fondo su modelo de datos. 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. Puede matar a una empresa por malas consultas o perder un gran cliente. Los datos tienen significado, los desarrolladores a menudo parecen olvidarlo.

Los datos casi nunca desaparecen, piense en términos de almacenamiento de datos a lo largo del tiempo en lugar de simplemente cómo obtenerlos hoy. Esa base de datos que funcionó bien cuando tenía cien mil registros, puede que no sea tan buena en diez años. Las aplicaciones rara vez duran tanto como los datos. Esta es una razón por la cual diseñar para el rendimiento es crítico.

Su base de datos probablemente necesitará campos que la aplicación no necesita ver. Cosas como GUID para replicación, fecha de inserción de campos. etc. También es posible que deba almacenar el historial de cambios y quién los realizó y cuándo podrá restaurar los cambios incorrectos desde este almacén. Piense en cómo piensa hacer esto antes de venir a preguntar 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 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 código, no hay excusa para no mantenerlo en el control de la fuente como el resto de su código.


6

Diseño de bases de datos evolutivas. http://martinfowler.com/articles/evodb.html

Estas metodologías ágiles hacen que el proceso de cambio de la 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 descartar después de un período de vida en todas las bases de datos de esta base de código.

Al menos sé, 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.


Me encanta el concepto de refactorización, pero con respecto a DB, el verdadero gran problema con él son los datos persistentes. La refactorización de DB a menudo implica la migración de datos, que en realidad es difícil, especialmente si no se le permite ningún tiempo de inactividad del sistema. También la reversión no es trivial. Desde mi punto de vista, las dificultades en la implementación adecuada / segura de las estrategias de despliegue + reversión a menudo son un obstáculo para refactorizar DB tan ligero como el código de la aplicación. En sí, a menudo tiene sentido refactorizar las cosas, pero siempre tienes que superar los costos / beneficios.
manuel aldana

Consulte también las 'Bases de datos de refactorización' de Ambler ( amazon.com/Refactoring-Databases-Evolutionary-Database-Design/… ).
Jonathan Leffler

5

Desde mi experiencia con bases de datos relacionales, cada desarrollador debe saber:

- Los diferentes tipos de datos :

Usar el 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.

- Conozca 1xM y MxM :

Este es el pan de cada día para las bases de datos relacionales. Debe comprender las relaciones uno a muchos y muchos a muchos y aplicarlas cuando sea apropiado.

- El principio " KISS " se aplica también a la base de datos :

La simplicidad siempre funciona mejor. Siempre que haya estudiado cómo funciona DB, evitará una complejidad innecesaria que conducirá a problemas de mantenimiento y velocidad.

- Índices :

No es suficiente si sabes lo que son. Debe comprender cuándo usarlos y cuándo no.


además:

  • El álgebra booleana es tu amiga
  • Imágenes: no las almacene en la base de datos. No preguntes por qué.
  • Prueba DELETE con SELECT

+1 para imágenes. Sin embargo, reemplazaría 'Imágenes' con 'BLOBs'.
Agnel Kurian

No estoy realmente seguro de la parte de "simplicidad". La base de datos más simple posible es una tabla gigante con un montón de varchar(max)columnas. Las bases de datos relacionales deberían normalizarse , no simplificarse .
Aaronaught

Sus preocupaciones están cubiertas anteriormente, en la parte de "tipos de datos" de mi publicación. Me refería al uso (innecesario) de procedimientos almacenados / disparadores / cursores, etc.
Anax

5

Me gustaría que todos, tanto los DBA como los desarrolladores / diseñadores / arquitectos, comprendan mejor cómo modelar adecuadamente un dominio comercial y cómo mapear / traducir ese modelo de dominio comercial en un modelo lógico de base de datos normalizado, un modelo físico optimizado y un modelo de clase orientado a objetos apropiado, 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í.


5

Yo diría fuertes habilidades básicas de SQL. He visto a muchos desarrolladores hasta ahora 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 (interior, izquierda, etc.) al consultar una base de datos bien normalizada.


5

Sobre el siguiente comentario a la respuesta de Walter M.:

"¡Muy bien escrito! Y la perspectiva histórica es excelente para las personas que no estaban trabajando en bases 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 repite los errores jerárquicos del pasado, grafica las bases de datos que repiten los errores de la red del pasado, los sistemas OO obligan al modelo jerárquico a los usuarios, mientras que todos, incluso con solo una décima parte de cerebro, deben saber que el modelo jerárquico no es adecuado para el uso general. representación del propósito del mundo real, etcétera, etcétera.

En cuanto a la pregunta en sí:

Todos los desarrolladores de bases de datos deben saber que "Relacional" no es igual a "SQL". Entonces entenderían por qué los vendedores de DBMS los decepcionan tan abismalmente, y por qué deberían decirles a esos mismos proveedores que propongan mejores cosas (por ejemplo, DBMS que sean realmente relacionales) si quieren seguir chupando cantidades hilarantes de dinero de sus clientes por un software tan malo).

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 estúpidas preguntas de "No sé cómo hacer mi trabajo y quiero que alguien más lo haga por mí" en Stack Overflow.


1
Estoy de acuerdo en que un desarrollador necesita saber dónde divergen SQL y RDM. Dicho esto, el uso juicioso del RDM puede ser una ayuda invaluable para el diseñador de la base de datos, incluso si la implementación es SQL.
Walter Mitty el

1
En caso de que lo hayas olvidado, George Santayana, escribió esa cita clásica ...
crosenblum

5

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 caigas en la trampa de "DBA conociendo a los mejores" 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 presione para que los DBA expliquen qué está sucediendo y cómo sus soluciones abordan el problema.

Presente sus propias sugerencias también después de haber realizado 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.


buena respuesta. Cada uno tenemos nuestra propia área, contribuimos a cada problema o solución.
crosenblum

5

Respeto simple

  • No es solo un repositorio
  • Probablemente no sepa mejor que el vendedor o los DBA
  • No lo apoyará a las 3 am con los gerentes senior gritándole

3

Considere la desnormalización 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 Entity-Relation es algo que todos los desarrolladores deben conocer, incluso si no diseñan bases de datos. Le permitirá comprender a fondo de qué se trata su base de datos.


3

Nunca inserte datos con la codificación de texto incorrecta.

Una vez que su base de datos se contamine con múltiples codificaciones, lo mejor que puede hacer es aplicar alguna combinación amable de heurística y trabajo manual.


2
¿Qué es la "codificación de texto incorrecta" y cómo sucede?
Gennady Vanin Геннадий Ванин

1
@ vgv8, ocurre cuando su cliente permite a los usuarios enviar texto en cualquier codificación que desee, y lo almacena a ciegas. Luego, cuando necesita realizar algún tipo de transformación o análisis, su código se rompe, porque su aplicación asume utf-8, pero algún idiota agregó datos utf-16, y su programa comete errores o comienza a escupir galimatías.
mikerobi

3

Además de la sintaxis y las opciones conceptuales que emplean (como uniones, desencadenantes y procedimientos almacenados), una cosa que será crítica para cada desarrollador que emplee una base de datos es esta:

Sepa cómo su motor va a 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. Debe saber cómo funciona su código para no detener toda la ejecución en su hilo mientras espera a que se complete una función larga, entonces, ¿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 afectado a mi equipo de I + D más veces que faltan puntos y comas o similares. 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 salga mal con otra consulta en otro lugar, lo que retrasará El resultado de esta consulta.

Incluso cosas simples como cómo las uniones afectan el rendimiento de una consulta son invaluables en la producción. Hay muchas características de muchos motores de bases de datos que facilitan las cosas conceptualmente, pero pueden introducir problemas en el rendimiento si no se piensa claramente.

Conozca el proceso de ejecución del motor de su base de datos y planifíquelo.


3

Para un desarrollador profesional intermedio que usa muchas bases de datos (escribir / mantener consultas diariamente 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. Todos los frikis gráficos escribieron un raytracer en la universidad. Cada web geek escribió sitios web interactivos (generalmente antes de que tuviéramos "marcos web") en la universidad. Cada nerd de hardware (e incluso nerds de software) construyó una CPU en la universidad. Todos los médicos diseccionaron un cadáver completo en la universidad, incluso si solo me va a tomar la presión arterial y me dicen 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 las partes internas de su RDBMS no deberían preocuparle demasiado .

Es prácticamente imposible obtener el mismo nivel de comprensión simplemente leyendo sobre ellos, o incluso trabajando desde la parte superior. Pero si comienza en la parte inferior y comprende cada pieza, es relativamente fácil descubrir los detalles de su base de datos. Incluso cosas que muchos geeks de la base de datos no pueden entender, como cuándo usar una base de datos no relacional.

Tal vez eso sea un poco estricto, especialmente si no estudiaste informática en la universidad. Lo atenuaré un poco: podrías escribir uno hoy , completamente, desde cero. No me importa si conoce los detalles de cómo funciona el optimizador de consultas PostgreSQL, pero si sabe lo suficiente como para escribir uno, probablemente no será muy diferente de lo que hicieron. Y sabes, realmente no es tan difícil escribir uno básico.


Del artículo vinculado de Joel sobre las cadenas C, ¿no el siguiente fragmento de plomo conduce a un comportamiento indefinido: char * str = "* Hello!"; str [0] = strlen (str) - 1; str es un literal de cadena y es general en la memoria de solo lectura. No puedes escribirle :?
HeretoLearn

Un experto en bases de datos profesional, bien, pero ¿ todos los desarrolladores ?
Ben Aston el

Ben: Todos los desarrolladores profesionales que usan bases de datos con frecuencia, sí. Realmente no son tan difíciles, así que si no sabes cómo, significa que nunca te has tomado ni un poco de tiempo para aprender cómo funcionan los DB. Todas las especialidades en informática que me gradué diseñaron una CPU e implementaron un sistema operativo. Una base de datos es más simple que cualquiera de estos, por lo que si pasa algún tiempo usando una, no veo una excusa para no saber cómo funcionan.
Ken

2

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, cardinalidad).

Esto es para ayudar a SQL Server a crear estadísticas útiles sobre cómo usar el índice en tiempo de ejecución.


-1 No es una buena idea seguir reglas como 'La primera columna debe ser la columna que tenga la mayor variabilidad en su contenido'. Si uno tiene algún conocimiento básico de cómo funcionan los índices, es simple ver cómo importa el orden y que el orden de la columna debe depender de la forma en que se consultará la tabla.
miracle173

gracias, pero si el índice se creó en 3 campos, sobre la base de que una consulta sql específica usará esos 3 campos en su cláusula where, entonces, el orden puede ser significativo, y el campo con la mayor cardinalidad que aparece primero \ anterior puede conducir a mejoras de rendimiento ... o al menos eso es lo que leí en un libro de ajuste de rendimiento de Microsoft SQL Server. Lo probé y pareció funcionar mejor (hace años).
Mike D

2

¡Entienda las herramientas que usa para programar la base de datos!

Perdí tanto tiempo tratando de entender por qué mi código fallaba misteriosamente.

Si está utilizando .NET, por ejemplo, necesita saber cómo usar correctamente los objetos en el System.Data.SqlClientespacio de nombres. Necesita saber cómo administrar suSqlConnection objetos para asegurarse de que estén abiertos, cerrados y, cuando sea necesario, dispuestos correctamente.

Debe saber que cuando usa un SqlDataReader, es necesario cerrarlo por separado de su SqlConnection. Debe comprender cómo mantener abiertas las conexiones cuando sea apropiado y cómo minimizar el número de visitas a la base de datos (porque son relativamente caras en términos de tiempo de computación).


2
  • Habilidades básicas de SQL.
  • Indexación.
  • Maneja diferentes encarnaciones de DATE / TIME / TIMESTAMP.
  • Controlador JDBCDocumentación del para la plataforma que está utilizando.
  • Tratar con tipos de datos binarios ( CLOB , BLOB , etc.)

1

Para algunos proyectos, y el modelo orientado a objetos es mejor.

Para otros proyectos, un modelo relacional es mejor.



1

Compatibilidad RDBMS

Mire si es necesario ejecutar la aplicación en más de un RDBMS. En caso afirmativo, podría ser necesario:

  • evitar las extensiones RDBMS SQL
  • eliminar disparadores y almacenar procedimientos
  • seguir estrictos estándares de SQL
  • convertir tipos de datos de campo
  • cambiar los niveles de aislamiento de transacciones

De lo contrario, estas preguntas deberían tratarse por separado y se desarrollarían diferentes versiones (o configuraciones) de la aplicación.


1

No dependa del orden de las filas devueltas por una consulta SQL.


3
... a menos que haya una ORDER BYcláusula en ella?
Aaronaught

Y no lo use ORDER BYinnecesariamente porque agrega carga al servidor SQL
Vivian River

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.