design patterns - gof - Patrones de base de datos
design patterns pdf (6)
Esta pregunta ya tiene una respuesta aquí:
- Patrones de diseño de bases de datos relacionales? 10 respuestas
¿Alguien sabe de papeles / libros / etc. que los patrones de documentos para bases de datos? Por ejemplo, una regla práctica común es que cada tabla debe tener una clave principal y que la clave debe estar desprovista de contenido de información . Entonces, me preguntaba si alguien había escrito un libro o publicado artículos sobre patrones de diseño para diseñar bases de datos relacionales.
@Gaius,
Esa es la pregunta que debe sopesar un diseñador de bases de datos: ¿cuál es la estabilidad probable de la estructura de la base de datos? Dado un horizonte suficientemente largo, nada es estable. O para decir lo contrario, dado un horizonte lo suficientemente largo, todo está sujeto a cambios. Una clave sustituta (en teoría) nunca debería cambiar su significado porque nunca tuvo un significado para comenzar.
Supongo que la otra cosa a considerar en ese escenario de diseño en particular es ¿quién será el que verá la clave principal? Si la clave primaria es algo a lo que los usuarios finales tendrán que referirse, entonces tiene sentido hacerlo algo que puedan entender. Pero no puedo pensar en muchos casos donde un usuario final necesita ver una clave primaria; generalmente, la clave primaria está presente para permitir que el motor DB acelere ciertas operaciones.
Mi idea original al hacer la pregunta fue encontrar patrones de diseño para el diseño de la base de datos que fueron codificados por diseñadores de bases de datos más experimentados que yo para evitar, con suerte, algunos errores fácilmente evitables. Sería interesante leer si alguien alguna vez codificó anti-patrones de diseño de bases de datos.
El uso de claves primarias con significado comercial ("claves naturales") ciertamente tiene sus ventajas, pero puede dificultar la refacturación de su base de datos. Tenga cuidado, especialmente si hay alguna razón para creer que la estructura de la base de datos cambiará con el tiempo.
En realidad, creo que la regla general es usar una clave natural en lugar de un sustituto siempre que sea posible ...
Entonces, si tengo, por ejemplo, una tabla de Factura y una tabla de FacturaDetallada, probablemente podamos usar el Número de Factura como nuestra clave primaria en la primera. Ya existe en nuestros datos y (supongo?) Sería único. Sin embargo, para la segunda tabla, probablemente estemos atrapados y necesitemos una clave sustituta, ya sea que esté unida al número de Factura como compuesto o no.
En cualquier caso, volviendo a la pregunta original ... el enlace de hometoast debería comenzar.
- Kevin Fairchild
Específicamente, con respecto a las claves: estoy totalmente en desacuerdo con la extraña idea de que las claves deben carecer de significado. En general, considero que una base de datos es una colección de hechos; tan pronto como comiences a agregar números arbitrarios (como claves generadas) y otra información irrelevante, debería ser una señal de advertencia. Recomiendo esto de manera unánime por Joe Celko para más información sobre las llaves.
Notas más generales:
Sugerencias para diseños de esquemas / modelos de datos para diferentes negocios: David C. Hay: Patrones de modelo de datos: Convenciones de pensamiento Bastante antiguo, pero hay una razón por la cual todavía está impreso
http://www.dorsethouse.com/books/dmp.html
Tal vez no muy parecido a un patrón, pero sigue siendo muy bueno: Stephane Faroult, Peter Robson: El arte de SQL http://oreilly.com/catalog/9780596008949/
Otro que puedo recomendar: Vadim Tropashko: Patrones de diseño de SQL: la guía experta para la programación de SQL http://www.rampant-books.com/book_2006_1_sql_coding_styles.htm
Libro de texto sistemático sobre modelado de datos: Graeme Simsion y Graham Witt, "Data Modeling Essentials" http://www.elsevierdirect.com/product.jsp?isbn=9780126445510
¿Tal vez está buscando una "guía de estilo" ?. Yo ese caso: Joe Celko: SQL Programming Style http://www.elsevierdirect.com/product.jsp?isbn=9780120887972
Los libros de EF Codd y CJ Date son las respuestas más obvias. No he leído este libro en particular, pero estoy familiarizado con los autores, es probable que sea bastante bueno.
Applied Mathmatics para profesionales de bases de datos por Lexx de Haan y Toon Koppelaars.
Para responder exactamente: yes . Hay s * -tons de información escrita en el ''buen'' diseño de la base de datos. Aunque la regla empírica ejemplar es ciertamente cuestionable.
SQL Anti-Patterns de Bill Karwin es muy fácil de leer (no está seco) y explica en términos bastante claros una serie de peligros potenciales diferentes, cómo puede utilizarlos y cómo / por qué hacer las cosas bien.