tool software google data database-design

database design - software - Mejores prácticas de diseño de bases de datos



database design software (14)

Estoy bastante versado con SQL Server, MySQL, Oracle, etc., pero dejando de lado estos productos de Base 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 por adelantado.

Al igual que con cualquier cosa, 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 el diseño y desarrollo.

Un sistema de base de datos OLTP se diseñará de forma completamente diferente a uno utilizado como una 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 podrían ser apropiadas.

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

Algunos puntos:

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

Diría que siempre que la base de datos esté normalizada y si está creando 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.

El libro de Michael J. Hernandez Database Design for Mere Mortals está bien escrito y es fácil de leer. Debería responder todas sus preguntas.

Hernández también es coautor de SQL Queries for Mere Mortals 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.

El mejor libro que he leído en cuanto al 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 he leído esto) y que es bastante bueno.

Diseño de base de datos para simples mortales

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 piensas 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 modelas. 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 adecuado para el diseño de la base de datos se 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 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 cumple . 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 sobre qué son, en particular, las consultas que 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.

Mi opinión sobre esto es algo contraria. 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 compres.

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 a pesar de que pueden otorgar un alto valor a los datos, lo que realmente están valorando es el software que está escribiendo.

Esto significa que concentraría la mayor parte de tu esfuerzo en construir 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 requiere mucho tiempo y, por lo general, lleva un tiempo hacerlo bien.

Entonces, te recomendaría que:

  1. Solo produce un diseño de DB cutre
  2. Reacciona a los escenarios reales de rendimiento que te encuentres
  3. Enfoca tus esfuerzos en la experiencia del usuario, no en la base de datos

No almacene valores calculados

Ejemplo, tiene tabla "Cuadrados" con columna "ancho". No es necesario hacer un "área" de columna, porque eso se puede calcular a través del ancho ^ 2

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

Para contrarrestar el consejo de Dillie-O. Sugeriría que no pongas todas tus búsquedas en una sola mesa. 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.

Dirígete a Google y busca "Tablas MUCK" que te llevarán a las discusiones sobre las tablas de clave de código unificadas masivamente. 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 .

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.

Un concepto que utilizamos aquí que ha demostrado ser muy agradable es la tabla del "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 usar si el código de búsqueda 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.

si no documenta las enumeraciones en la columna de descripción del esquema para que pueda descubrir cuál es el ''5'' en esto:

Select name from peeps where accountStatusId = 5

entonces haz esto

Usa una tabla para enumerar un campo. p.ej:

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