Patrones de diseño de bases de datos relacionales? [cerrado]

283

Los patrones de diseño generalmente están relacionados con el diseño orientado a objetos.
¿Existen 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:

  • Almacenar datos jerárquicos (por ejemplo, tabla única con tipo frente a tablas múltiples con clave 1: 1 y diferencias ...)
  • Almacenar datos con estructura variable (por ejemplo, columnas genéricas vs xml vs columnas delimitadas ...)
  • Desormalizar datos (cómo hacerlo con un impacto mínimo, etc.)
design-patterns database-design rdbms revs Sklivvz
fuente
Voy a reclamar las mejores preguntas y respuestas aquí para el almacenamiento jerárquico de datos: stackoverflow.com/questions/4048151/…
orangepips
1
De acuerdo con nuestra guía sobre el tema , " Algunas preguntas todavía están fuera de tema, incluso si encajan en una de las categorías enumeradas anteriormente: ... Preguntas que nos solicitan recomendar o encontrar un libro, herramienta, biblioteca de software, tutorial u otro los recursos fuera del sitio están fuera de tema ... "
Robert Columbia
@RobertColumbia la pregunta fue sobre el tema en 2008, cuando se le preguntó ...
Sklivvz
Consulte esta lista de recursos de patrones de diseño en bases de datos relacionales y muchas áreas de ingeniería de software github.com/DovAmir/awesome-design-patterns
dov.amir

Respuestas:

150

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 los patrones del modelo de datos de David C. Hay y el seguimiento de 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 un gran lugar para buscar algunos modelos de bases de datos pre-enlatados es la serie de libros de recursos del modelo de datos de Len Silverston, el volumen 1 contiene modelos de datos universalmente aplicables (empleados, cuentas, envíos, compras, etc.), el volumen 2 contiene modelos de datos específicos de la industria (contabilidad, atención médica, etc.), el Volumen 3 proporciona patrones de modelo de datos.

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

Michael Brown
fuente
1
El libro se titula [Refactorización de bases de datos: diseño de bases de datos evolutivas] [1] por Scott W. Ambler y Pramod J. Sadalage y, de hecho, es muy bueno. [1]: ambysoft.com/books/refactoringDatabases.html
Panos
3
Con respecto al libro de Ambler: No, no puede enumerar "insertar una columna" o "crear restricción FK" como un patrón por la misma razón. El libro Gang of 4 no enumera el ciclo "for" como patrón.
Tegiri Nenashi
No es un patrón, es una refactorización. Al igual que el método de extracción, o cambiar el nombre del parámetro. Refactorización y patrones van de la mano.
Michael Brown
Uno para agregar: "Patrones de análisis" de Fowler. Similar a las cosas de Hay
Neil McGuigan
2
El Volumen 3 de Len Silverston es el único que consideraría como "Patrones de diseño". Los primeros 2 muestran modelos de datos de muestra que eran comunes en el período de tiempo en que se escribieron los libros. Sin embargo, el Volumen 3 en realidad tiene múltiples patrones de diseño para un escenario de problema dado. Por ejemplo, el capítulo 4 cubre jerarquías / agregaciones / escenarios de igual a igual, y luego ofrece múltiples diseños que abordan los que tienen ventajas y desventajas de cada uno.
DarrellNorton
46

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

Los patrones de diseño son reutilizables, por definición. Son patrones que 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 de uno a muchos (maestro-detalle, padre-hijo) relaciones usando una clave foránea.

  2. Relaciones de muchos a muchos con una mesa de bridge.

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

  4. Star-Schema: Dimension and Fact, 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 pre-unidas que violan la segunda y tercera forma normal.

  9. Array mesa. 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, así 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 utilizan regularmente.

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

S.Lott
fuente
Algunos otros patrones que he visto son la tabla secundaria de varios padres (es decir, como notas globales con un tipo de objeto y un objectid que pueden vincularse a cualquier otra tabla), o una FK autorreferencial (es decir, employee.manager -> employee. carné de identidad). También he usado una tabla de configuración singleton que tiene muchas columnas.
r00fus
1
¿Por qué exactamente una base de datos de uso mixto es un antipatrón? ¿Qué debo hacer si quiero extraer informes de una base de datos?
oliva
3
@lhnz: No se puede tirar de una gran cantidad de grandes informes de un diseño de base de datos transaccional - bloqueo para la presentación de informes se ralentizará transacciones. Las uniones complejas (realizadas una y otra vez) son otro golpe contra el rendimiento de la transacción. No puede hacer ambas cosas en una base de datos. Para hacer muchos informes grandes, debe mover los datos a un esquema en estrella. El patrón de esquema en estrella está optimizado para generar informes. Y mover los datos elimina cualquier contención de bloqueo.
S.Lott
¿Normalizar el esquema reduciría la contención de bloqueo de fila si está haciendo que las tablas contengan más datos "coherentes"? Mi opinión es que si una tabla grande estaba prestando servicio a las escrituras en 2 tipos de conjuntos de datos pero ambos están en la misma fila, esto daría lugar a una contención de bloqueo innecesaria.
CMCDragonkai
6

AskTom es probablemente el recurso más útil para las mejores prácticas en Oracle DB. (Normalmente 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).

Dicho esto, puede considerar el "Almacenamiento de datos" como un "patrón" o enfoque algo separado en el diseño de la base de datos. En particular, es posible que le interese leer sobre el esquema Star .

Galghamon
fuente
4

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

preguntas:

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

No se usa:

  • espacios en blanco en los nombres de tabla y columna
  • 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 "DE", "ENTRE", "BORRAR", etc.

recomendaciones:

  • Use NVARCHAR o equivalentes para soporte Unicode, entonces no tiene problemas con las páginas de códigos.
  • Dale 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 lanza duro 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.

Horrocrux7
fuente
77
Aunque sus comentarios son bastante instructivos y útiles, no son patrones de diseño. Son las mejores prácticas. Gracias
Sklivvz
77
No estoy de acuerdo con la recomendación de nombres de columna únicos. Prefiero decir customer.id para desambiguar que decir customerid incluso donde no hay nada para desambiguar.
Paul Tomblin
1

Su pregunta es un poco vaga, pero supongo que UPSERTpodría considerarse un patrón de diseño. Para los idiomas que no se implementan MERGE, hay varias alternativas para resolver el problema (si existe una fila adecuada,UPDATEINSERT existen contrario ).

Sören Kuklau
fuente
UPSERT es un comando y parte del lenguaje SQL. No es un patrón.
Todd R
UPSERT es un comando en algunas variantes del lenguaje SQL: varias plataformas no lo tienen, o solo lo obtuvieron recientemente.
Steve Homer
@ToddR - He oído decir (ligeramente cínicamente) que los "patrones" no son más que deficiencias en un lenguaje o modelo, para los cuales el usuario debe crear soluciones. No sé qué hace UPSERT, pero si bien se ha agregado a algunos SQL y no a otros, es un patrón.
Martin F
1

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 el 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.

Andrew no es el santo
fuente
¿Qué pasa con la herencia de la base de datos como (persona, cliente, empleado) tal vez ese tipo de cosas podría considerarse como patrón de diseño?
Muflix