¿Cómo enfoca el diseño de la base de datos? [cerrado]

El mejor libro que compré sobre diseño de bases de datos fue Diseño de base de datos para mortales mortales por Michael Hernandez ISBN: 0-201-69471-9. Listado de Amazon Noté que tiene una tercera edición.

Enlace a la tercera edición

Te guía a través de todo el proceso de (desde el principio hasta el final) de diseñar una base de datos. Te recomiendo que comiences con este libro.

Tienes que aprender a mirar las cosas en grupos o partes. El diseño de la base de datos tiene bloques de construcción simples como lo hace la programación Si obtiene una comprensión profunda de estos simples bloques de construcción, puede abordar cualquier diseño de base de datos.

En programación tienes:

• Si construye
• Si Else construye
• Do While Loops
• Hacer hasta bucles
• Casos de construcción

Con las bases de datos tienes:

• Tablas de datos
• Tablas de búsqueda
• Relaciones uno a uno
• Una a muchas relaciones
• Muchas a muchas relaciones
• Claves primarias
• Claves foráneas

Cuanto más simple hagas las cosas mejor. Una base de datos no es más que un lugar donde se colocan datos en agujeros de cubos. Comience por identificar cuáles son estos agujeros de cubos y qué tipo de cosas quiere en ellos.

Nunca vas a crear el diseño perfecto de la base de datos la primera vez que lo intentes. Esto es un hecho. Su diseño pasará por varias mejoras durante el proceso. A veces, las cosas no se ven bien hasta que comienzas a ingresar datos, y luego tienes un momento ah ha

La web trae sus propios conjuntos de desafíos. Cuestiones de ancho de banda. La apatridia. Datos erróneos de procesos que se inician pero que nunca se terminan.

Realizo tanto la programación orientada a objetos como el diseño de la base de datos (en su mayoría transaccional, pero algo de OLAP) y, en mis circunstancias, hay muchos temas recurrentes (al menos con OLTP).

Practicar la normalización 3nf me ayuda a practicar alguna variante del principio de responsabilidad única. Una tabla debe representar un concepto en su sistema, y los conceptos deben relacionarse entre sí de manera que intenten imitar la realidad; por ejemplo, si estoy creando un sistema en el que un Cliente puede tener 0 o muchas Actividades, entonces creo una Tabla de Clientes y una Tabla de Actividades. La tabla de actividades tiene una relación de clave externa con la tabla Cliente. Cuando estoy creando procedimientos almacenados, me aseguraría de usar una unión externa para unir al Cliente y la actividad porque el requisito empresarial de que un Cliente pueda tener 0 actividades.

También estoy atento a las oportunidades de extensibilidad mediante el uso de tablas puente (enlace). Por ejemplo, si estuviera tratando de representar una regla de negocios en la que un libro podría tener un número ilimitado (variable) de autores, crearía una Tabla de libros, una Tabla de autores y una tabla de enlace / enlace que tenga referencias de clave externa a ambos Libro y Autor.

Además, uso claves sustitutas en todas las tablas (normalmente columnas de identidad de auto-incremento, pero tal vez Guids: la compensación con las guids en el código es que ocupan más espacio de memoria que un simple número entero), y evito depender de los recursos naturales claves para mis búsquedas (excepto con Bridge / Link Tables). De forma predeterminada, también creo índices en columnas de clave externa común y reviso procedimientos almacenados / consultas del sistema de vez en cuando para optimizar las estrategias de indexación. Otra estrategia de indexación que utilizo es buscar lugares en mi código donde construyo una colección basada en una columna de búsqueda, y agregue los índices apropiados a las columnas de búsqueda.

Primero diseño el esquema de mi base de datos y luego uso un ORM para crear los objetos a partir de él. Soy un poco vieja escuela de esa manera; No confío en que ORM cree un esquema de base de datos inteligente y eficiente. Ese es el trabajo de los humanos, y parte del arte del diseño de software.

Encontré que el libro de Bill Karwin, Antipatterns SQL , es realmente útil para la planificación de bases de datos. El punto que señala de manera más general es que la base de datos ofrece muchas oportunidades para proteger la integridad y el significado de sus datos, y que es un error común de los diseñadores ignorar estas funciones por varias razones tentadoras. Vale la pena considerar estos problemas desde el principio y dejar que informen sobre todo el diseño, y es mejor intentar eliminar las grietas más tarde.

Prefiero usar una base de datos que tenga restricciones integrales para imponer la integridad y la lógica de negocios en el nivel de la base de datos. A menudo veo la base de datos como la aplicación y cualquier cosa que acceda a ella como una mera interfaz. Esto hace que la adición de otras "interfaces" sea una experiencia más agradable y directa, y tiene beneficios positivos para la seguridad.

También creo que es importante considerar la estructura de la base de datos como una entidad cambiante, en lugar de asumir que es necesario envolverla y sellarla antes de comenzar cualquier otra cosa. Debe planificar el cambio y acomodar la base de datos en su sistema de control de versiones. Hay un buen ensayo sobre esto: Diseño de la base de datos evolutiva por Martin Fowler & Pramod Sadalage (y también un libro completo sobre el tema de Sadalage, aunque no he leído esto).

Por último, los problemas periféricos de cuentas / roles de usuario, hardware / ubicación / conexión de host, etc. son importantes y, a veces, se pasan por alto. Tenga esto en cuenta también al planificar.

el diseño de la base de datos no se puede hacer completamente sin considerar cómo se utilizarán los datos, por lo que aquí hay una breve lista de pasos:

• escriba oraciones cortas que capturen la relación entre entidades
• dibuje un diagrama de entidad-relación que represente las oraciones
• cree un modelo de datos lógico normalizado a partir del diagrama de E-R
• haga una matriz CRUD para aplicaciones y entidades
• use la matriz para verificar la cobertura del ciclo de vida de cada entidad
• extraer subschemas para cada aplicación
• examine las rutas de navegación a través de los subesquemas para cada operación principal / CRUD
• considere los informes que se requerirán
• diseñar el modelo de datos físicos basado en todo lo anterior; Desnormalizar, particionar y usar esquemas en estrella donde sea apropiado

Para diseñar con éxito una base de datos, primero debe considerar varias cosas:

• ¿Qué datos necesito almacenar y cómo? ¿Está relacionado con los otros datos que almacenar. ¿Cómo necesitarán estos datos ¿cambian con el tiempo? Necesito ser capaz de ver una instantánea en el tiempo (que orden de 2009) o solo necesito ¿Qué es actual (solo usuarios activos)?
• ¿Cómo puedo asegurarme de que mis datos están significativo y mantiene el significado sobre tiempo (integridad de los datos)?
• ¿Cómo puedo asegurarme de que el acceso a los datos es rápido?
• ¿Cómo puedo mantener mis datos seguros?

Entonces, antes de comenzar a diseñar una base de datos, primero debe aprender sobre la normalización y las características de una base de datos utilizada para mantener la integridad de los datos.

Entonces necesitas entender el ajuste de rendimiento. Esto no es prematuro, el rendimiento es el punto crítico de falla de la mayoría de las bases de datos y es muy difícil de solucionar una vez que tenga millones de registros.

Y, finalmente, debe comprender cómo proteger los datos y qué datos deben protegerse y qué controles internos necesita para garantizar que los datos no se modifiquen de manera malintencionada o para poder realizar un seguimiento de los cambios a lo largo del tiempo para descubrir quién y cuándo se realizó un cambio y poder volver a las versiones anteriores.

También es útil leer un poco acerca de las bases de datos de refactorización antes de comenzar, ya que tendrá que hacerlo más tarde y es útil saber cómo configurar las cosas para que pueda refactorizar lo más fácilmente posible.

En general, los datos sobreviven a la aplicación por muchos años, es el corazón de la aplicación y no deben considerarse como un almacén de datos estúpido que en su mayoría es irrelevante.

En términos generales, un buen diseño de la base de datos es un buen diseño de la base de datos: la pregunta más importante para el uso de la web será cómo acceder a los datos y administrar las cosas que uno podría considerar requieren un estado que básicamente la web no tiene.

Pensando en ello, mi enfoque se basa en una experiencia bastante más bien ... pero ya sea que comience con un esquema o con objetos, está intentando hacer lo mismo, es decir, construir un modelo utilizable de sus datos, para una Un número sustancial de proyectos puede ser una relación bastante directa entre el modelo y el esquema (no en todos los casos, y probablemente no para todas las tablas / objetos), por lo que realmente se trata de construir un modelo decente comenzando donde sea cómodo y trabajando. desde allí.

En términos de construir un modelo decente, @Tim lo tiene para las bases de datos y, fundamentalmente, la construcción de su modelo de objetos será muy similar: lo que es único, lo que es una jerarquía, dónde hay muchas relaciones, etc. Sin embargo, al llegar a una base de datos, asegúrate de hacer todas las cosas buenas.

También asegúrate de tener scripts o ddl en el código que te permitan crear el esquema desde cero y actualizarlo a medida que realizas cambios (ddl en el código es mi método preferido: tengo un sistema y funciona).

Empiezo con una pizarra grande y un montón de diferentes colores de bolígrafo. Diferentes colores significan diferentes cosas. Y acabo de empezar a dibujar. Por lo general, dibujo cosas que están definidas en negro, cosas que son probablemente en azul y cosas que son poco probables en verde. El rojo es para notas importantes. Borré y redibuje copiosamente. Pienso en qué tipo de cosas necesito consultar y me aseguro de que el modelo lo admita. Si no lo hago voy a pellizcar hasta que lo haga.

Eventualmente, si el modelo se vuelve demasiado grande, lo moveré a Visio y volveré a trabajar en la pizarra.

Último pienso en puntos de extensión. El error más grande que veo que la mayoría de la gente hace es diseñar su base de datos y luego decir "Ya terminé con la base de datos" y seguir adelante. Nunca has terminado con la base de datos. Es probable que cada solicitud de cambio que reciba descienda hasta ese nivel. Así que piensa en cómo agregarlo. Piense en qué tipos de solicitudes son posibles y vea si puede conectarlas. Si no piensa en absoluto sobre la extensibilidad, tendrá una gran deuda de diseño cuando surjan esas solicitudes de cambio. p>

En cuanto a "SQL luego ORM" o viceversa, eso depende de usted. Solo asegúrate de que tu modelo sea una buena base primero.

Primero diseño los objetos y luego uso un ORM (como nHibernate) para crear el esquema. Me da mucha más flexibilidad que hacer lo inverso.

El siguiente paso es la optimización del esquema generado.

Hace mucho tiempo que no veo un proyecto donde se diseñaron primero las tablas de la base de datos.

Pocas cosas no expresadas explícitamente hasta ahora por otros miembros:

• Es mejor que el diseño de la base de datos sea realizado por alguien que sea profesional. Está bien aprender, por supuesto, pero no sugeriría construir un modelo mediano o grande si uno no está bien versado en modelado o diseño de bases de datos. La razón de esto es que el costo de un diseño incorrecto suele ser muy alto.

• Conozca bien los objetivos del sistema y los requisitos del usuario. Sin conocer los requisitos, no puede diseñar el modelo de datos correcto.

• Sepa qué código hacer en los programas y qué código dejar que cuide la DB. Esto es necesario para que establezca la columna de datos nula, no nula, etc. correctamente. Esto también es necesario para que especifique su RI correctamente.

• Determine bien sus claves primarias. Vaya por claves simples cuando pueda.

• Considere las necesidades de integración con otras aplicaciones.

• Considere el uso de modelos de datos universales y siga los estándares de la industria en cuanto al tamaño de las columnas de datos y nombres.

• Piense en las necesidades futuras (cuando se conozcan y cuando corresponda)

• Haga que otros revisen su modo.

• Use una herramienta para modelar: una herramienta ERD o una herramienta UML.

• Revise y comprenda el código DDL generado. No lo des por sentado.