Patrones de diseño de bases de datos relacionales?

Question

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

Los ejemplos incluyen las pautas de diseño de la tabla, 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, una sola mesa con el tipo frente a múltiples tablas con 1: 1 llave y diferencias ...)
• almacenamiento de datos con de estructura variable (por ejemplo, columnas genéricos vs XML vs columna delimitada ...)
• datos desnormalizar (cómo hacerlo con un mínimo impacto, etc ...)

Answer 1

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

También recomendaría altamente el Data Model Patterns de David C. Hay y el seguimiento A Metadata Map que se basa en el primero y es mucho más ambicioso e intrigante. El Prefacio solo es esclarecedor.

También es un buen lugar para buscar algunos modelos de bases de datos pre-enlatado es Modelo de Datos de Recursos libro de la serie Volume 1 de Len Silverston contiene los modelos de datos de aplicación universal (empleados, cuentas, envío, compras, etc.), Volume 2 contiene modelos de datos específicos de la industria (contabilidad, cuidado de la salud, etc.), Volume 3 proporciona patrones de modelos de datos.

último, si bien este libro es ostensiblemente sobre UML y modelado de objetos, Peter Coad de Modeling in Color With UML proporciona un proceso de "arquetipo" impulsado de modelado de entidad a partir de la premisa de que hay 4 arquetipos básicos de cualquier modelo de objetos/datos

Answer 2

Los libros de Joe Celko son excelentes para este tipo de cosas, en particular "SQL for Smarties". Él 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

Answer 3

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

preguntas:

• ¿Desea usar en el futuro otro DBMS? En caso afirmativo, entonces no se usa para el material SQL especial del DBMS actual. Eliminar la lógica en su aplicación.

No usa:

• espacios en blanco en los nombres de tablas y columnas
• caracteres no ASCII en la tabla y columna nombres
• que se unen a un caso específico menor o mayúsculas. Y nunca use 2 tablas o columnas que difieran solo con minúsculas y mayúsculas.
• no utiliza palabras clave de SQL para tablas o columnas nombres como "FROM", "entre", "BORRAR", etc

recomendaciones:

• Uso NVARCHAR o los equivalentes de un soporte Unicode entonces no tienes problemas con las páginas de códigos.
• Dale a cada columna un nombre único. Esto hace que sea más fácil unirse para seleccionar la columna. Es muy difícil si cada tabla tiene una columna "ID" o "Nombre" o "Descripción". Use XyzID y AbcID.
• Utilice un paquete de recursos o igual para expresiones SQL complejas. Facilita el cambio a otro DBMS.
• No pesa mucho 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.

Answer 4

Su pregunta es un poco vaga, pero supongo que UPSERT podría considerarse un patrón de diseño. Para lenguajes que no implementan MERGE, a number of alternatives to solve the problem (si existe una fila adecuada, UPDATE; sino INSERT) existe.

Answer 5

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

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

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

patrones de diseño relacional incluyen cosas como:

relaciones

1. -uno a muchos (maestro-detalle, padre-hijo) relaciones usando una clave externa.

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

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

4. Star-Schema: Dimension and Fact, OLAP design.

5. Diseño OLTP completamente normalizado.

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

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

8. Uni-table. [Algunos llaman esto un antipatrón; es un patrón, a veces es malo, a veces es bueno.] Esta es una tabla con muchas cosas preunidas que violan la segunda y tercera forma normal.

9. Array table. 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 usos mixtos. 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, así que sigue siendo un patrón.

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

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

Answer 6

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

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

Tal vez si usted tiene que construir una base de datos con rapidez esto le dará un punto de partida en términos de las tablas y relaciones en un esquema determinado. Tenga en cuenta que probablemente necesite modificar este punto de partida. Lo he encontrado muy útil.

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

Answer 7

Depende de lo que quiere decir con un patrón. Si está pensando en Persona/Empresa/Transacción/Producto y tal, entonces sí, hay muchos esquemas genéricos de bases de datos 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 bases de datos.

Si está pensando en nombrar objetos de base de datos, entonces está bajo la categoría de convenciones, no de diseño per se.

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

Answer 8

AskTom es probablemente el recurso más útil sobre las mejores prácticas en Oracle DB. (Normalmente 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, puede considerar "Data Warehousing" como un "patrón" o enfoque algo separado en el diseño de la base de datos. En particular, puede que le interese leer sobre el Star schema.

Answer 9

Echa un vistazo a este blog - The Database Programmer.

Describe algunos database patterns.

Answer 10

This book looks interesting

Title: Data Patterns 
By: Microsoft Corporation 
Publisher: Microsoft Press 
Pub. Date: December 21, 2004 
Print ISBN-13: 978-0-7356-2200-5