Mejores prácticas de diseño de bases de datos

Question

Estoy bastante bien versado en SQL Server, MySQL, Oracle, etc. pero dejando de lado estos productos de bases de datos, ¿hay algún recurso que me ayude a diseñar bien las bases de datos relacionales? ¿Hay algo así como patrones o mejores prácticas para el diseño de la base de datos?

He visto algunas veces que la base de datos a menudo no es escalable; las personas tienen preferencias personales para mantener columnas como la columna isChecked, que es de naturaleza booleana pero almacenada como Char (1) con valores como 'Y' y 'N' en lugar de 0 y 1, lo que a mí me suena mejor. Formas de no cometer errores comunes al hacer el diseño de la base de datos?

Los enlaces a libros o artículos serán muy apreciados.

Gracias de antemano.

Answer 1

unos pocos puntos:

• Aprenda todo lo que pueda sobre problema de dominio. No se puede crear un buen modelo de datos sin saber lo que está diseñando para
• Tener un buen conocimiento de los tipos de datos proporcionados por su proveedor de base de datos
• cómo utilizar correctamente normalización y diseño de tablas
• Rendimiento: cuándo y cómo aplicar índices, cómo escribir consultas eficientes etc.
• ¿Cuándo y cómo utilizar diferentes objetos de base de datos como vistas, procedimientos, funciones, disparadores

Answer 2

Posiblemente la mejor práctica más famosa es la normalización de la base de datos. Este conjunto de técnicas le permite diseñar su base de datos para que los elementos redundantes se eliminen y los campos se agrupen lógicamente.

Answer 3

Como en todo, la respuesta aquí es "Depende".

Las bases de datos se pueden usar para hacer cosas diferentes, y algunas de esas cosas requerirán direcciones opuestas en diseño y desarrollo.

Un sistema de base de datos OLTP se diseñará de forma completamente diferente a uno utilizado como solución de informes o almacenamiento. El primero a menudo se normaliza y un almacén a menudo se desnormaliza. Esto ayuda al sistema a obtener el rendimiento deseado para su comportamiento previsto.

Incluso dentro de un segmento de esto, dependiendo de si el uso será de lectura pesada o de escritura pesada, las decisiones de diseño diferentes pueden ser apropiadas.

La mejor opción es buscar las mejores prácticas para un segmento mucho más pequeño de desarrollo de bases de datos que corresponda al tipo de aplicación que intentas construir.

Answer 4

Un concepto que utilizamos aquí que ha demostrado ser muy agradable es la tabla "Código de búsqueda". Si tiene una base de datos que tiene muchas referencias a elementos que efectivamente codifican, o tipos, o similares, manténgalos todos en una sola tabla LookupCode que basa las cosas fuera de un CodeGroup y del Código mismo.

Mantenemos un indicador adicional para el estado activo del código, así como algunas columnas numéricas opcionales que se pueden utilizar si el código de búsqueda dado debe ser ordenado o calculado de cualquier manera.

Al hacer esto, elimina tener toneladas de pequeñas tablas dispersas alrededor de su esquema. Ahora, una de las desventajas de esto es que la clave principal para la tabla es el código del grupo y el código en sí, así que no hay una clave externa adjunta a la tabla "maestra" que hace referencia a un código dado, pero un poco de la aplicación en la aplicación es fácil de acomodar para esto.

Answer 5

diría que mientras se normalice la base de datos y si está haciendo un VLDB, entonces participen correctamente, entonces debería estar bien. otras mejores prácticas incluyen el uso de CRUD para los procedimientos almacenados y garantizar que todas las tablas funcionen correctamente. la mayoría de todo lo demás es subjetivo. El uso de "S/N" es la programación de la base de datos de la vieja escuela desde cuando aún no se ha introducido el bit. También se puede usar para propósitos de escalabilidad como "S/N/Tal vez", pero si ese fuera el caso, las prácticas de bast bastarían para normalizar eso y hacer una tabla de búsqueda.

Answer 6

El mejor libro que he leído en relación con el diseño de bases de datos es "Diseño de bases de datos para simples mortales" por Michael J. Hernández.El nombre suena como un libro para principiantes, pero las personas de cualquier nivel pueden obtener conocimiento de él. También es independiente de la plataforma, ya que trata de ver los datos en sí y cómo organizarlos adecuadamente, no la tecnología que se utiliza.

También escribió un libro sobre cómo escribir consultas llamadas "Consultas SQL para simples mortales" que he escuchado (aún no lo he leído) es bastante bueno.

Database Design for Mere Mortals

Answer 7

Existen numerosos patrones de diseño de base de datos. No suelen estar muy bien formalizados, por lo que es posible que simplemente tenga que mirar mucho diseño de la base de datos.

Consulte, por ejemplo, Fowler's books en patrones de diseño. También Nock's Book.

Hay blogs, como database programmer.

Hay un libro de IEEE, On Pattern-Based Database Design and Implementation.

La búsqueda de Google (link) obtuvo 24 millones de visitas.

Answer 8

valores almacén No calculados

ejemplo, tiene tabla "Squares" con la columna "ancho". No es necesario hacer una columna "área", porque eso se puede calcular a través del ancho^2

Answer 9

Mi opinión sobre esto es algo contrario. Aconsejo, no enfatice demasiado el diseño de la base de datos.

A veces esto puede ser difícil. Con las aplicaciones internas de LOB, la visión que prevalece en el negocio muchas veces es que DATA es el activo principal, mientras que el software es algo prescindible.

Mi consejo sería: no lo compre.

En realidad, el activo es la capacidad de la empresa para INTERACTUAR con los datos. Para verlo, manipularlo y tomar decisiones basadas en él.

Esto significa que, aunque pueden valorar mucho los datos, lo que realmente valoran es el software que está escribiendo.

Esto significa que concentraría la mayor parte de su esfuerzo en crear una experiencia de usuario efectiva, en lugar de en "diseñar la base de datos perfecta". La base de datos es realmente una herramienta que le permite ofrecer una experiencia de usuario.

La característica clave de los modelos de datos relacionales es la independencia de la ruta de acceso e información. Puede agregar columnas, cambiar claves, introducir o eliminar índices, etc., teniendo cero impacto (o cerca de cero) en las aplicaciones que lo usan.

Esto hace que la estructura de la base de datos sea extremadamente flexible.

Tratar de diseñar la base de datos para "ser flexible para el futuro" u "optimizar el rendimiento" es principalmente un esfuerzo desperdiciado.

Cambiar la estructura de la base de datos tendrá un impacto relativamente pequeño en su sistema.

Además, realmente no se puede predecir cómo se escalará la base de datos hasta que se encuentre con los escenarios donde se necesita escalar. Su mejor apuesta es esperar hasta que llegue a problemas de rendimiento. y luego abordarlos específicamente.

Sin embargo, realizar cambios en la experiencia del usuario de su aplicación suele ser más costoso. El trabajo de IU consume mucho tiempo y, por lo general, lleva tiempo hacerlo bien.

lo tanto, yo le recomendaría que:

1. Sólo producir un diseño DB chungo
2. reaccionar a los escenarios reales de rendimiento que encuentro
3. centrar sus esfuerzos en la experiencia del usuario, no en la base de datos

Answer 10

si no documenta las enumeraciones en la columna Descripción del esquema de modo que pueda averiguar lo que el '5' es en esto:

Select name from peeps where accountStatusId = 5 

luego hacer esto

Uso una tabla para enumerar un campo. por ejemplo:

Select name 
from peeps p 
join accountStatus s 
on p.accountStatusID = s.asid 
where s.accountStatus = 'ActiveDude' 

Answer 11

Para contrarrestar el consejo de Dillie-O. Sugeriría que no haga ponga todas sus búsquedas en una sola tabla. En general, este es un intento de forzar el diseño de OO en una Base de datos relacional. Se puede hacer y se ajusta a la visión del mundo de un desarrollador OO, pero conduce a diseños de bases de datos paralizantes.

Regresa a Google y busca "Tablas de MUCK" que te llevarán a discusiones sobre Tablas de clave de código masivamente unificadas. Alternativamente, puede buscar "una tabla de búsqueda verdadera" para las discusiones. O incluso lea el artículo de Joe Celko One True Lookup Table.

Answer 12

La base de datos relacional es una abstracción extremadamente poderosa; es una colección de hechos y un cálculo de predicados. No solo eso, SQL impone la separación de consultas de comando al tener una cláusula para examinar filas y otra para cambiar filas.

Cuando piense en una base de datos como un motor de razonamiento de verdad, tiene sentido tener una configuración que no permita que las contradicciones fluyan de los datos que está modelando. Por lo tanto, para usar una base de datos relacional de manera efectiva, necesita obtener el diseño correcto de su base de datos. A diferencia del diseño de programas orientados a objetos, existe una opinión consensuada sobre cómo debe diseñarse una base de datos relacional.El enfoque correcto para el diseño de la base de datos es normalise en la medida de lo razonable. La mayoría de las personas normaliza hasta la tercera forma normal, pero de hecho puede llegar a la quinta forma normal.

Si es posible, desea borrar los valores de columna nulos de su base de datos. Si está de acuerdo con mi punto de vista de la base de datos como un motor de razonamiento de verdad, entonces los nulos son un problema real. Cuando tiene nulos en una base de datos, la ley del medio excluido no se no espera. Esto hace que la "prueba por contradicción" de cualquier propiedad dada de la base de datos sea más difícil de lo que sería sin los nulos. Los nulos complican innecesariamente la semántica de la base de datos.

A veces será necesario romper las reglas de normalización por motivos de rendimiento. Sin embargo, no hagas esto antes de que tengas datos en lo que las consultas en particular son lentas. A menudo puede simplemente acelerar la consulta modificando cuidadosamente los índices en lugar de desnormalizar.

Finalmente, una palabra sobre procedimientos almacenados en lugar de consultas directas. En una base de datos decente, puede establecer permisos de seguridad en procedimientos almacenados independientemente de las tablas subyacentes. Esto, por sí solo, es motivo suficiente para considerar el uso extensivo de procedimientos almacenados. Con los procedimientos almacenados, crea un modelo de seguridad más estricto que el que es posible con acceso directo a SQL.

Answer 13

El libro de Michael J. Hernandez El diseño de la base de datos para Mere Mortals está bien escrito, y es fácil de leer. Debería responder todas sus preguntas.

Hernandez también es co-autor Consultas SQL para simples mortales con John L. Viescas.

Los libros cuestan alrededor de $ 60 por pieza. Intento encontrar el CD de Consultas para simples mortales porque perdí el mío. Si alguien tiene una copia, házmelo saber.

Answer 14

No encontré lo que estaba buscando en esta pregunta, pero this one tiene un montón de recomendaciones para los patrones de diseño en el diseño de DB