design patterns - tipos - ¿Patrones de diseño de bases de datos relacionales?
patrones estructurales (10)
Aquí hay un enlace a un caballero que ha desarrollado varios cientos de esquemas de base de datos gratuitos.
http://www.databaseanswers.org/data_models/
Quizás si tienes que construir una base de datos rápidamente, esto te dará un punto de partida en términos de las tablas y las relaciones en un esquema determinado. Tenga en cuenta que probablemente necesitará 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 educativa y, a menudo, contiene esquemas completos para un sistema determinado.
Los patrones de diseño suelen estar 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, desencadenadores, etc.
¿Hay 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 (p. Ej., Tabla única con tablas de tipo vs tablas múltiples con clave 1: 1 y diferencias ...)
- Almacenar datos con estructura variable (por ejemplo, columnas genéricas vs xml vs columna delimitada ...)
- Desnormalizar datos (cómo hacerlo con un impacto mínimo, etc ...)
Depende de lo que quieras decir con un patrón. Si está pensando en Persona / Compañía / Transacción / Producto y tal, entonces sí, hay muchos esquemas de bases de datos genéricos disponibles.
Si estás pensando en Factory, Singleton ... entonces no, no necesitas ninguno de estos, ya que son demasiado bajos para la programación de DB.
Si está pensando en nombrar los objetos de la base de datos, entonces está en la categoría de convenciones, no en diseño por sí mismo.
Por cierto, S.Lott, las relaciones de uno a muchos y de muchos a muchos no son "patrones". Son los componentes básicos del modelo relacional.
Después de muchos años de desarrollo de bases de datos, puedo decir que hay algunos que no va y algunas preguntas que debe responder antes de comenzar:
preguntas:
- ¿Quieres usar en el futuro otro DBMS? Si es así, entonces no se utiliza para cosas SQL especiales del DBMS actual. Eliminar la lógica en su aplicación.
No se usa:
- espacios en blanco en los nombres de tablas y columnas
- Caracteres no Ascii en nombres de tablas y columnas.
- vinculante a una minúscula específica o mayúscula. Y nunca use 2 tablas o columnas que difieran solo con minúsculas y mayúsculas.
- no usa palabras clave SQL para tablas o nombres de columnas como "FROM", "BETWEEN", "DELETE", etc.
recomendaciones:
- Utilice NVARCHAR o equivalentes para el soporte de Unicode, entonces no tiene problemas con las páginas de códigos.
- Dale a cada columna un nombre único. Esto hace que sea más fácil en la unión para seleccionar la columna. Es muy difícil si cada tabla tiene una columna "ID" o "Nombre" o "Descripción". Utilice XyzID y AbcID.
- Utilice un paquete de recursos o iguales para expresiones complejas de SQL. Facilita el cambio a otro DBMS.
- No lanza duro en ningún tipo de datos. Otro DBMS no puede tener este tipo de datos. Por ejemplo, las tarjetas Oracle no tienen un SMALLINT solo un número.
Espero que este sea un buen punto de partida.
Echa un vistazo a este blog - El programador de base de datos .
Describe algunos patrones de base de datos .
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 base de datos.
También recomendaría encarecidamente los Patrones de modelo de datos de David C. Hay y el Mapa de metadatos de seguimiento 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 precocinados. El Volumen 1 de la Serie de libros de recursos para el modelo de datos de Len Silverston 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, cuidado de la salud, etc.), el volumen 3 proporciona patrones de modelos de datos.
Finalmente, mientras este libro es aparentemente sobre UML y Modelado de Objetos, Peter Coad Modeling in Color With UML proporciona un proceso de modelado de entidades basado en "arquetipos" a partir de la premisa de que existen 4 arquetipos centrales de cualquier modelo de objeto / datos.
Los libros de Joe Celko son excelentes para este tipo de cosas, en particular "SQL para Smarties". Tiene algunas soluciones innovadoras para problemas comunes, la mayoría de los cuales son patrones de diseño reutilizables.
Los patrones de diseño no son soluciones trivialmente reutilizables.
Los patrones de diseño son reutilizables, por definición. Son patrones que detectas en otras buenas soluciones.
Un patrón no es reutilizable trivialmente. Sin embargo, puede implementar su diseño descendente siguiendo el patrón.
Los patrones de diseño relacional incluyen cosas como:
Relaciones de uno a muchos (maestro-detalle, padre-hijo) mediante una clave externa.
Relaciones de muchos a muchos con una mesa de bridge.
Relaciones uno a uno opcionales gestionadas con NULL en la columna FK.
Esquema en estrella: dimensión y hecho, diseño OLAP.
Diseño OLTP completamente normalizado.
Múltiples columnas de búsqueda indexadas en una dimensión.
"Tabla de búsqueda" que contiene PK, descripción y valor (es) de código usados 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.
Uni-mesa. [Algunos llaman a esto un anti-patró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 la tercera forma normal.
Tabla de matriz. Esta es una tabla que viola la primera forma normal al tener una matriz o secuencia de valores en las columnas.
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 anti-patró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 decir una media docena "Es otra de esas"; Estos son patrones de diseño que utilizan de forma regular.
Y esto no incluye los patrones administrativos y operativos de uso y gestión.
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 manteniendo 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, podría considerar el "almacenamiento de datos" como un "patrón" o enfoque un tanto separado en el diseño de la base de datos. En particular, podría interesarle leer sobre el esquema en estrella .
Title: Data Patterns
By: Microsoft Corporation
Publisher: Microsoft Press
Pub. Date: December 21, 2004
Print ISBN-13: 978-0-7356-2200-5
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 ; de lo contrario, INSERT ).