Patrones de diseño de bases de datos relacionales?

StackOverflow https://stackoverflow.com/questions/145689

Pregunta

Los patrones de diseño generalmente están relacionados con el diseño orientado a objetos.
¿Hay patrones de diseño para crear y programar bases de datos relacionales ?
Muchos problemas seguramente deben tener soluciones reutilizables.

Los ejemplos incluirían patrones para el diseño de tablas, procedimientos almacenados, disparadores, etc. ...

¿Existe un repositorio en línea de tales patrones, similar a martinfowler.com ?

Ejemplos de problemas que los patrones podrían resolver:

  • Almacenamiento de datos jerárquicos (por ejemplo, tabla única con tipo frente a tablas múltiples con clave 1: 1 y diferencias ...)
  • Almacenamiento de datos con estructura variable (por ejemplo, columnas genéricas frente a xml frente a columna delimitada ...)
  • Desormalizar datos (cómo hacerlo con un impacto mínimo, etc.)
¿Fue útil?

Solución

Hay un libro en la serie Signature de Martin Fowler llamado Refactoring Databases . Eso proporciona una lista de técnicas para refactorizar bases de datos. No puedo decir que haya escuchado tanto una lista de patrones de bases de datos.

También recomendaría altamente los Patrones del modelo de datos de David C. Hay y el seguimiento Un mapa de metadatos que se basa en el primero y es mucho más ambicioso e intrigante. El prefacio solo es esclarecedor.

También es un gran lugar para buscar algunos modelos de bases de datos predefinidos es la serie de libros de recursos del modelo de datos de Len Silverston Volumen 1 contiene modelos de datos universalmente aplicables (empleados, cuentas, envíos, compras, etc.), Volumen 2 contiene modelos de datos específicos de la industria (contabilidad, salud, etc.), Volumen 3 proporciona patrones de modelo de datos.

Finalmente, si bien este libro es aparentemente sobre UML y modelado de objetos, Modelado en color con UML de Peter Coad proporciona un "arquetipo" proceso dirigido de modelado de entidades a partir de la premisa de que hay 4 arquetipos centrales de cualquier modelo de objeto / datos

Otros consejos

Aquí hay un enlace a un caballero que ha desarrollado varios cientos de esquemas de bases de datos gratuitos.

http://www.databaseanswers.org/data_models/

Quizás si tiene que construir un db rápidamente, esto le dará un punto de partida en términos de tablas y relaciones en un esquema dado. Tenga en cuenta que probablemente necesitará modificar este punto de partida. Lo he encontrado muy útil.

En segundo lugar, la revista SQL Server tiene una columna ocasional llamada "The Data Modeler". que es muy educativo y que a menudo contiene esquemas completos para un sistema dado.

Los patrones de diseño no son soluciones trivialmente reutilizables.

Los patrones de diseño son reutilizables, por definición. Son patrones que usted detecta en otras buenas soluciones.

Un patrón no es trivialmente reutilizable. Sin embargo, puede implementar su diseño descendente siguiendo el patrón.

Los patrones de diseño relacional incluyen cosas como:

  1. Relaciones uno a muchos (maestro-detalle, padre-hijo) relaciones usando una clave foránea.

  2. Relaciones de muchos a muchos con una tabla puente.

  3. Relaciones opcionales uno a uno administradas con NULL en la columna FK.

  4. Esquema estelar: dimensión y hecho, diseño OLAP.

  5. Diseño OLTP completamente normalizado.

  6. Múltiples columnas de búsqueda indexadas en una dimensión.

  7. " Tabla de búsqueda " que contiene PK, descripción y valores de código utilizados por una o más aplicaciones. ¿Por qué tener código? No lo sé, pero cuando tienen que usarse, esta es una forma de administrar los códigos.

  8. Uni-mesa. [Algunos lo llaman antipatrón; es un patrón, a veces es malo, a veces es bueno.] Esta es una tabla con muchas cosas previamente unidas que viola la segunda y tercera forma normal.

  9. Tabla de matriz. Esta es una tabla que viola la primera forma normal al tener una matriz o secuencia de valores en las columnas.

  10. Base de datos de uso mixto. Esta es una base de datos normalizada para el procesamiento de transacciones pero con muchos índices adicionales para informes y análisis. Es un antipatrón, no hagas esto. La gente lo hace de todos modos, por lo que sigue siendo un patrón.

La mayoría de las personas que diseñan bases de datos pueden recitar fácilmente media docena "Es otra de esas" estos son patrones de diseño que usan regularmente.

Y esto no incluye patrones administrativos y operativos de uso y gestión.

Los libros de Joe Celko son excelentes para este tipo de cosas, en particular "SQL for Smarties". Tiene algunas soluciones innovadoras para problemas comunes, la mayoría de los cuales son patrones de diseño reutilizables.

http://www.celko.com/books.htm

AskTom es probablemente el recurso más útil sobre las mejores prácticas en Oracle DBs. (Por lo general, solo escribo "asktom" como la primera palabra de una consulta de Google sobre un tema en particular)

No creo que sea realmente apropiado hablar de patrones de diseño con bases de datos relacionales. Las bases de datos relacionales ya son la aplicación de un "patrón de diseño". a un problema (el problema es "cómo representar, almacenar y trabajar con datos mientras se mantiene su integridad", y el diseño es el modelo relacional). Otros enfoques (generalmente considerados obsoletos) son los modelos de navegación y jerárquicos (y estoy seguro de que existen muchos otros).

Habiendo dicho eso, podría considerar " Data Warehousing " como un "patrón" algo separado o enfoque en el diseño de bases de datos. En particular, puede estar interesado en leer sobre el Esquema de estrella .

Después de muchos años de desarrollo de bases de datos, puedo decir que hay algunos no va y alguna pregunta que debe responder antes de comenzar:

preguntas :

  • ¿Desea usar en el futuro otro DBMS? En caso afirmativo, no se utiliza para cosas especiales de SQL del DBMS actual. Elimine la lógica en su aplicación.

No utiliza:

  • espacios en blanco en nombres de tablas y columnas
  • Caracteres no ASCII en nombres de tabla y columna
  • vinculante a una minúscula o mayúscula específica. Y nunca use 2 tablas o columnas que difieran solo con minúsculas y mayúsculas.
  • no utiliza palabras clave SQL para nombres de tablas o columnas como " FROM " ;, " BETWEEN " ;, " DELETE " ;, etc

recomendaciones:

  • Use NVARCHAR o equivalentes para soporte Unicode, entonces no tiene problemas con las páginas de códigos.
  • Dé a cada columna un nombre único. Esto facilita la unión para seleccionar la columna. Es muy difícil si cada tabla tiene una columna '' ID '' o " Nombre " o "Descripción". Use XyzID y AbcID.
  • Use un paquete de recursos o iguales para expresiones SQL complejas. Facilita el cambio a otro DBMS.
  • No se convierte en ningún tipo de datos. Otro DBMS no puede tener este tipo de datos. Por ejemplo, Oracle no tiene un SMALLINT solo un número.

Espero que este sea un buen punto de partida.

Su pregunta es un poco vaga, pero supongo que UPSERT podría considerarse un patrón de diseño. Para los idiomas que no implementan MERGE , existen varias alternativas para resolver el problema (si existe una fila adecuada, UPDATE ; else INSERT ) existe.

Depende de lo que quieras decir con un patrón. Si está pensando en Persona / Compañía / Transacción / Producto y tal, entonces sí, ya hay muchos esquemas de bases de datos genéricos disponibles.

Si está pensando en Factory, Singleton ... entonces no, no necesita ninguno de estos, ya que tienen un nivel demasiado bajo para la programación de DB.

Si está pensando en la denominación de objetos de la base de datos, está en la categoría de convenciones, no en diseño per se.

Por cierto, S.Lott, las relaciones uno a muchos y muchos a muchos no son "patrones". Son los componentes básicos del modelo relacional.

Este libro parece interesante 

Title: Data Patterns
By: Microsoft Corporation
Publisher: Microsoft Press
Pub. Date: December 21, 2004
Print ISBN-13: 978-0-7356-2200-5
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top