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

Principalmente soy desarrollador web y tengo un par de proyectos personales que quiero iniciar.

Una cosa que me está molestando es el diseño de la base de datos. He pasado por la normalización de db en la escuela y cosas así, pero ha sido hace un par de años y nunca he tenido experiencia con el diseño de bases de datos relacionales, excepto en la escuela.

Entonces, ¿cómo aborda la base de datos desde la perspectiva de una aplicación web? ¿Cómo comienzas y a qué te fijas? ¿Qué son las banderas de precaución?

El mejor libro que compré sobre diseño de bases de datos fue Diseño de bases de datos para simples mortales de Michael Hernández ISBN: 0-201-69471-9. Listado de Amazon Me di cuenta de que tiene una tercera edición.

Enlace a la tercera edición

Él lo guía a través de todo el proceso de diseño de una base de datos (de principio a fin). Te recomiendo que comiences con este libro.

Tienes que aprender a mirar las cosas en grupos o trozos. El diseño de la base de datos tiene bloques de construcción simples al igual que la programación. Si adquiere una comprensión profunda de estos bloques de construcción simples, puede abordar cualquier diseño de base de datos.

En programación tienes:

• Si construye
• Si otras construcciones
• Hacer bucles while
• Hacer hasta bucles
• Construcciones de casos

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
• Llaves extranjeras

Cuanto más simple hagas las cosas, mejor. Una base de datos no es más que un lugar donde pones datos en cubículos. Comience por identificar cuáles son estos agujeros de cubbie y qué tipo de cosas desea en ellos.

Nunca va a crear el diseño perfecto de la base de datos la primera vez que lo intente. Esto es un hecho. Su diseño pasará por varias mejoras durante el proceso. A veces las cosas no parecerán aparentes hasta que comiences a ingresar datos, y luego tengas un momento ah ja .

La web trae sus propios desafíos. Problemas de ancho de banda. Apatridia. Datos erróneos de procesos que comienzan pero nunca terminan.

Hago programación orientada a objetos y diseño de bases de datos (principalmente transaccionales, pero algunos OLAP), y para 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 modo que intenten imitar la realidad; por ejemplo, si estoy construyendo 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 construyo procedimientos almacenados, me aseguro de usar una combinación externa para unirme al Cliente y la actividad porque el requisito comercial de que un Cliente puede tener 0 actividades.

También vigilo las oportunidades de extensibilidad mediante el uso de tablas de puente (enlace). Por ejemplo, si intentara representar una regla comercial en la que un libro podría tener un número ilimitado (variable) de autores, crearía una Tabla de libros, una tabla de Autor y una tabla de puente / enlace que tiene referencias de claves externas a ambos Libro y autor.

Además, uso claves sustitutas en todas las tablas (generalmente columnas de identidad de incremento automático, pero tal vez Guías: la compensación con las guías en el código es que ocupan más espacio de memoria que un entero simple), y evito depender de las claves naturales para mi búsquedas (excepto con tablas de puente / enlace). De manera predeterminada, también creo índices en columnas de clave externa comunes y reviso los procedimientos almacenados / consultas del sistema de vez en cuando para optimizar las estrategias de indexación. Otra estrategia de indexación que uso es buscar lugares en mi código donde construyo una colección basada en una columna de búsqueda y agrego índices apropiados a las columnas de búsqueda.

Primero diseño mi esquema de base de datos, luego uso un ORM para crear los objetos a partir de él. Soy un poco vieja escuela de esa manera; No confío en los ORM para crear 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, SQL Antipatterns , es realmente útil para la planificación de bases de datos. El punto más completo 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 características por varias razones tentadoras. Vale la pena considerar estos problemas desde el principio y dejar que informen que todo el diseño vale la pena y supera el intento de superar las grietas más tarde.

Prefiero usar una base de datos que tenga restricciones integrales para imponer la lógica e integridad del negocio a 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 suponer que necesita envolverla y sellarla antes de comenzar cualquier otra cosa. Debe planificar el cambio y acomodar la base de datos en su sistema de versiones. Hay un buen ensayo sobre esto: Diseño de base de datos evolutiva por Martin Fowler y 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 las cuentas / roles de usuario, hardware / ubicación / conexión del host, etc. son importantes y a veces se pasan por alto. Tenga esto en cuenta también cuando planifique.

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

• escribir oraciones cortas capturando la relación entre entidades
• dibujar un diagrama de entidad-relación que represente las oraciones
• crear un modelo de datos lógicos normalizado a partir del diagrama ER
• hacer una matriz CRUD para aplicaciones y entidades
• use la matriz para verificar la cobertura del ciclo de vida de cada entidad
• extraer subesquemas para cada aplicación
• examinar las rutas de navegación sobre los subesquemas para cada operación principal / CRUD
• considerar 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 cuando sea apropiado

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

• Qué datos necesito almacenar y cómo se relacionan con los otros datos que almaceno. ¿Cómo deberán cambiar estos datos con el tiempo? ¿Necesito poder ver una instantánea a tiempo (ese pedido desde 2009) o solo necesito lo que es actual (solo usuarios activos)?
• ¿Cómo puedo asegurarme de que mis datos sean significativos y mantengan su significado a lo largo del tiempo (integridad de datos)?
• ¿Cómo puedo asegurarme de que el acceso a los datos sea 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 necesita comprender el ajuste del 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 tiene millones de registros.

Y, por último, 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 maliciosamente o para poder realizar un seguimiento de los cambios a lo largo del tiempo para averiguar quién y cuándo Se realizó un cambio y poder volver a las versiones anteriores.

También es útil leer un poco sobre la refactorización de bases de datos antes de comenzar, ya que habrá que refactorizarlas más adelante 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 tonto que es irrelevante.

En términos generales, un buen diseño de base de datos es un buen diseño de 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 bastante mucha experiencia ... pero si comienzas con un esquema u objetos, en realidad estás tratando de hacer lo mismo, es decir, construir un modelo utilizable de tus datos, para un número sustancial de es probable que exista 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 la construcción de un modelo decente: @Tim lo tiene para las bases de datos y, fundamentalmente, la construcción de su modelo de objetos será muy similar: qué es único, qué es una jerarquía, dónde hay muchas o muchas relaciones, etc. llegar a una base de datos, asegúrese de hacer todo lo bueno.

También asegúrese de tener scripts o ddl en el código para permitirle crear el esquema desde cero y actualizarlo a medida que realiza cambios (ddl en el código es mi método preferido, tengo un sistema y funciona).

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

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

Por último, pienso en los puntos de extensión. El error más grande que veo que la mayoría de la gente comete es diseñar su base de datos y luego decir "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 llegue hasta ese nivel. Así que piense en cómo agregarle. Piense en qué tipos de solicitudes son probables y vea si puede engancharlas. Si no piensa en absoluto en la extensibilidad, tendrá una gran deuda de diseño cuando surjan esas solicitudes de cambio.

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

Primero diseño 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.

Ha pasado mucho tiempo desde que vi un proyecto donde las tablas de la base de datos se diseñaron primero.

Pocas cosas no mencionadas explícitamente hasta ahora por otros compañeros:

• Es mejor que el diseño de la base de datos sea realizado por alguien 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 se encargue el 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 principales. Busca llaves simples cuando puedas.

• 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 nombres y tamaño de columna de datos.

• Piense en las necesidades futuras (cuando se conocen y cuando corresponde)

• Haz que otros revisen tu modo.

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

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