Patrones de bases de datos [duplicado]

Question

Esta pregunta ya tiene respuesta aquí:

• ¿Patrones de diseño de bases de datos relacionales? 10 respuestas

¿Alguien sabe de artículos/libros/etc.que documentan patrones para bases de datos?Por ejemplo, una regla general común es que cada tabla debe tener una clave principal y que la clave debe ser carente de contenido informativo.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.

---

@Gayo,

Ésa es la pregunta que un diseñador de bases de datos debe sopesar: ¿cuál es la probable estabilidad de la estructura de la base de datos?Dado un horizonte suficientemente largo, nada es estable.O, para decir lo contrario, dado un horizonte suficientemente largo, todo está sujeto a cambios.Una clave sustituta (en teoría) nunca debería cambiar su significado porque, para empezar, nunca tuvo significado.

Supongo que la otra cosa a considerar en ese escenario de diseño particular es ¿quién verá la clave principal?Si la clave principal es algo a lo que los usuarios finales realmente necesitarán consultar, entonces tiene sentido convertirla en algo que puedan entender.Pero no se me ocurren muchos casos en los que un usuario final necesite ver una clave principal;Por lo general, la clave principal está presente para permitir que el motor de base de datos acelere ciertas operaciones.

Mi idea original al hacer la pregunta fue encontrar patrones de diseño para el diseño de bases de datos que fueran codificados por diseñadores de bases de datos con más experiencia que yo para, con suerte, evitar algunos errores fácilmente evitables.Sería una lectura interesante si alguien alguna vez hubiera codificado antipatrones de diseño de bases de datos.

Answer 1

En concreto, respecto a las claves:Estoy totalmente en desacuerdo con la extraña idea de que las claves no deben tener significado.En general, considero una base de datos una colección de hechos;Tan pronto como comience a agregar números arbitrarios (como claves generadas) y otra información irrelevante, debería ser una señal de advertencia.recomiendo esto articulamente por Joe Celko para más información sobre las claves.

Notas más generales:

Sugerencias para diseños de esquemas/modelos de datos para diferentes negocios:David C.Heno:Patrones de modelo de datos:Convenciones de pensamiento bastante antiguas, pero hay una razón por la que todavía está impresa
http://www.dorsethouse.com/books/dmp.html

Quizás no muy parecido a un patrón, pero aún así es muy bueno:Stéphane Faroult, Peter Robson:El arte de SQLhttp://oreilly.com/catalog/9780596008949/

Otro que puedo recomendar:Vadim Tropashko:Patrones de diseño SQL: la guía experta para la programación SQLhttp://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, "Conceptos básicos del modelado de datos"http://www.elsevierdirect.com/product.jsp?isbn=9780126445510

¿Quizás en realidad estás buscando una "guía de estilo"?Yo ese caso:Joe Celko:Estilo de programación SQLhttp://www.elsevierdirect.com/product.jsp?isbn=9780120887972

Answer 2

Libros de E.F.Codd y C.J.La fecha son las respuestas más obvias.No he leído este libro en particular, pero conozco a los autores y probablemente sea bastante bueno.

Matemáticas aplicadas para profesionales de bases de datos de Lexx de Haan y Toon Koppelaars.

Answer 3

En realidad, creo que la regla general suele ser utilizar una clave natural en lugar de una sustituta siempre que sea posible...

Entonces, si tengo, por ejemplo, una tabla Invoice y una tabla InvoiceDetail, probablemente podamos usar InvoiceNumber como nuestra clave principal en la primera.Ya existe en nuestros datos y (¿supongo?) sería único.Sin embargo, para la segunda tabla, probablemente nos quedaremos atrapados necesitando una clave sustituta, ya sea que esté unida al número de factura como compuesta o no.

En cualquier caso, volvamos a la pregunta original...El enlace de hometoast debería ayudarle a comenzar.

--Kevin Fairchild

Answer 4

Para responder exactamente: Sí.Hay toneladas de información escrita sobre un "buen" diseño de base de datos.Aunque su ejemplo, la regla general es ciertamente cuestionable.

Answer 5

Antipatrones de SQL de Bill Karwin es muy fácil de leer (no aburrido) y explica en términos bastante claros una serie de posibles errores diferentes, cómo podría terminar utilizándolos y cómo y por qué hacer las cosas bien.

Answer 6

El uso de claves primarias con significado comercial ("claves naturales") ciertamente tiene sus ventajas, pero puede dificultar la refactorización de su base de datos. muy difícil.Tenga cuidado, especialmente si hay algún motivo para creer que la estructura de la base de datos cambiará con el tiempo.