Modelli di database [duplicato]

Question

Questa domanda ha già una risposta qui:

• Modelli di progettazione di database relazionali? 10 risposte

Qualcuno sa di documenti/libri/ecc.che documentano i modelli per i database?Ad esempio, una regola pratica comune è che ogni tabella dovrebbe avere una chiave primaria e che la chiave dovrebbe esserlo privo di contenuto informativo.Quindi mi chiedevo se qualcuno avesse scritto un libro o pubblicato articoli sui modelli di progettazione per la progettazione di database relazionali?

---

@Gaius,

Questa è la domanda che un progettista di database deve valutare: qual è la probabile stabilità della struttura del database?Dato un orizzonte sufficientemente lungo, nulla è stabile.O per dire il contrario, dato un orizzonte sufficientemente lungo, tutto è soggetto a cambiamenti.Una chiave surrogata (in teoria) non dovrebbe mai cambiare il suo significato perché non ha mai avuto significato fin dall'inizio.

Immagino che l'altra cosa da considerare in quel particolare scenario di progettazione sia chi vedrà la chiave primaria?Se la chiave primaria è qualcosa a cui gli utenti finali dovranno effettivamente fare riferimento, allora ha senso renderla qualcosa che possano comprendere.Ma non riesco a pensare a molti casi in cui un utente finale abbia bisogno di vedere una chiave primaria;solitamente la chiave primaria è presente per permettere al motore del DB di velocizzare determinate operazioni.

Il mio pensiero originale nel porre la domanda era quello di trovare modelli di progettazione per la progettazione di database che fossero codificati da progettisti di database più esperti di me in modo da, si spera, evitare alcuni errori facilmente evitabili.Sarebbe interessante leggere se qualcuno avesse mai codificato anti-pattern di progettazione di database.

Answer 1

Nello specifico, per quanto riguarda le chiavi:Sono assolutamente in disaccordo con la strana idea che le chiavi debbano essere prive di significato.In generale considero un database una raccolta di fatti;non appena inizi ad aggiungere numeri arbitrari (come le chiavi generate) e altre informazioni irrilevanti, dovrebbe essere un segnale di avvertimento.raccomando questo articolo di Joe Celko per ulteriori informazioni sulle chiavi.

Note più generali:

Suggerimenti per progetti di schemi/modelli di dati per diverse aziende:David C.Fieno:Modelli di modello di dati:Convenzioni di pensiero piuttosto vecchio, ma c'è un motivo per cui è ancora in stampa
http://www.dorsethouse.com/books/dmp.html

Forse non molto simile a uno schema, ma comunque molto buono:Stephane Faroult, Peter Robson:L'arte dell'SQLhttp://oreilly.com/catalog/9780596008949/

Un altro che posso consigliare:Vadim Tropashko:SQL Design Patterns: la guida esperta alla programmazione SQLhttp://www.rampant-books.com/book_2006_1_sql_coding_styles.htm

Libro di testo sistematico sulla modellazione dei dati:Graeme Simsion e Graham Witt, "Elementi essenziali per la modellazione dei dati"http://www.elsevierdirect.com/product.jsp?isbn=9780126445510

Forse stai effettivamente cercando una "guida allo stile"?.In questo caso:Joe Celko:Stile di programmazione SQLhttp://www.elsevierdirect.com/product.jsp?isbn=9780120887972

Answer 2

Libri di E.F.Codd e C.J.La data è la risposta più ovvia.Non ho letto questo libro in particolare ma conosco gli autori, probabilmente è abbastanza buono.

Matematica applicata per professionisti di database di Lexx de Haan e Toon Koppelaars.

Answer 3

In realtà, penso che la regola pratica sia tipicamente quella di usare una chiave naturale piuttosto che una surrogata quando possibile...

Quindi, se ho, ad esempio, una tabella Invoice e una tabella InvoiceDetail, probabilmente possiamo utilizzare InvoiceNumber come chiave primaria sulla prima.Esiste già nei nostri dati e (presumo?) Sarebbe unico.Per la seconda tabella, probabilmente non avremo bisogno di una chiave surrogata, indipendentemente dal fatto che sia unita al numero di fattura come composito o meno.

In ogni caso, tornando alla domanda iniziale...il collegamento di hometoast dovrebbe aiutarti a iniziare.

--Kevin Fairchild

Answer 4

Per rispondere esattamente: SÌ.Ci sono un sacco di informazioni scritte sulla "buona" progettazione del database.Anche se la regola pratica del tuo esempio è certamente discutibile.

Answer 5

Anti-pattern SQL di Bill Karwin è molto facile da leggere (non arido) e spiega in termini abbastanza chiari una serie di diverse potenziali trappole, come potresti ritrovarti a usarle e come/perché fare le cose nel modo giusto.

Answer 6

L'uso di chiavi primarie con significato aziendale ("chiavi naturali") ha sicuramente i suoi vantaggi, ma può rendere necessario il refactoring del database molto difficile.Prestare attenzione, soprattutto se c'è motivo di ritenere che la struttura del database cambierà nel tempo.