¿Patrones de Diseño de Bases de Datos Relacionales?

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 /

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

En segundo lugar, la revista SQL Server tiene una columna ocasional llamada " El Modelador de datos" que es muy educativo y 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 detectas 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 un extranjero clave.

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

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

4. Star-Schema: Dimension and Fact, OLAP design (en inglés).

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? Me no lo sé, pero cuando tienen que ser utilizados, esta es una forma de administrar los códigos.

8. 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 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 normalizado para el procesamiento de transacciones, pero con muchos índices adicionales para informes y análisis. Es un anti-patrón't 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 fácilmente decir media docena de "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 gestión.

Echa un vistazo a este blog - El Programador de Bases de Datos.

Describe algunos patrones de base de datos .

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. (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 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 algo separado en el diseño de bases de datos. En particular, le puede interesar leer sobre el esquema de estrellas .

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

Preguntas:

• ¿Desea utilizar en el futuro otro DBMS? Si es así, entonces no se usa para cosas SQL especiales del DBMS actual. Elimina la lógica de tu aplicación.

No utilice:

• espacios en blanco en nombres de tablas y nombres de columnas
• Caracteres no Ascii en tabla y columna nombres
• enlace 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 el soporte unicode, entonces no tendrá problemas con las páginas de códigos.
• Dé a cada columna un nombre único. Esto hace que sea más fácil al unirse 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 SQL complejas. Hace que sea más fácil cambiar a otro DBMS.
• No casting duro en ningún tipo de datos. Otro DBMS no puede tener este tipo de datos. Por ejemplo Oracle daes 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 UPSERT podría considerarse un patrón de diseño. Para lenguajes que no implementan MERGE, existen varias alternativas para resolver el problema (si existe una fila adecuada, UPDATE; else INSERT).

Depende de lo que quieras decir con un patrón. Si usted está pensando Persona / Empresa / Transacción / Producto y tal, entonces sí-hay una gran cantidad de esquemas de base de datos genéricos ya disponibles.

Si estás pensando en Fábrica, Singleton... entonces no, no necesita ninguno de estos, ya que son demasiado bajos 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 diseño per se.

POR cierto, S. Lott, uno a muchos y muchos a muchos las relaciones no son "patrones". Son los bloques 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