Modelli di progettazione di database relazionali? [chiuso]

283

I modelli di progettazione sono generalmente correlati alla progettazione orientata agli oggetti.
Esistono modelli di progettazione per la creazione e la programmazione di database relazionali ?
Molti problemi devono sicuramente avere soluzioni riutilizzabili.

Gli esempi includono modelli per la progettazione di tabelle, procedure memorizzate, trigger, ecc.

Esiste un repository online di tali modelli, simile a martinfowler.com ?

Esempi di problemi che i modelli potrebbero risolvere:

Memorizzazione di dati gerarchici (ad es. Tabella singola con tipo vs più tabelle con chiave 1: 1 e differenze ...)
Memorizzazione di dati con struttura variabile (ad es. Colonne generiche vs xml vs colonne delimitate ...)
Denormalizzare i dati (come farlo con un impatto minimo, ecc ...)

design-patterns database-design rdbms

— Sklivvz
fonte

Chiederò le migliori domande e risposte qui per l'archiviazione dei dati gerarchica: stackoverflow.com/questions/4048151/…

— orangepips

1

Secondo la nostra guida in tema , " Alcune domande sono ancora fuori tema, anche se rientrano in una delle categorie sopra elencate: ... Domande che ci chiedono di raccomandare o trovare un libro, uno strumento, una libreria software, un tutorial o altro le risorse fuori sede sono fuori tema ... "

— Robert Columbia,

@RobertColumbia la domanda era in tema nel 2008, quando è stata posta ...

— Sklivvz,

Dai un'occhiata a questo elenco di risorse di modelli di progettazione su database relazionali e su molte aree dell'ingegneria del software github.com/DovAmir/awesome-design-patterns

— dov.amir

150

C'è un libro nella serie Signature di Martin Fowler chiamato Refactoring D Database . Ciò fornisce un elenco di tecniche per il refactoring dei database. Non posso dire di aver sentito così tanto un elenco di schemi di database.

Consiglio vivamente anche i modelli di dati modello di David C. Hay e il follow-up A Metadata Map che si basa sul primo ed è molto più ambizioso e intrigante. La prefazione da sola è illuminante.

Un altro ottimo posto in cui cercare alcuni modelli di database predefiniti è il volume di dati Serie 1 del libro delle risorse del modello di Len Silverston che contiene modelli di dati universalmente applicabili (dipendenti, account, spedizioni, acquisti, ecc.), Il volume 2 contiene modelli di dati specifici del settore (contabilità, assistenza sanitaria, ecc.), Volume 3 fornisce modelli di modelli di dati.

Infine, mentre questo libro parla apparentemente di UML e Object Modeling, la modellazione a colori con UML di Peter Coad fornisce un processo "archetipo" di modellazione di entità a partire dal presupposto che ci sono 4 archetipi principali di qualsiasi modello di oggetto / dati

— Michael Brown
fonte

1

Il libro è intitolato [Refactoring D Database: Evolutionary Database Design] [1] di Scott W. Ambler e Pramod J. Sadalage ed è davvero molto buono. [1]: ambysoft.com/books/refactoringD Database.html

— Panos

3

Per quanto riguarda il libro Ambler: No, non puoi elencare "l'inserimento di una colonna" o "la creazione del vincolo FK" come modello per lo stesso motivo. Il gruppo Gang of 4 non elenca il ciclo "for" come modello.

— Tegiri Nenashi,

Non è uno schema, è un refactoring. Come il metodo extract o rinomina il parametro. Refactoring e modelli vanno di pari passo.

— Michael Brown,

Uno da aggiungere: "Pattern di analisi" di Fowler. Simile alle cose di Hay

— Neil McGuigan,

2

Il volume 3 di Len Silverston è l'unico che prenderei in considerazione come "Design Patterns". I primi 2 mostrano modelli di dati di esempio che erano comuni nel lasso di tempo in cui i libri sono stati scritti. Il volume 3 ha in realtà più modelli di progettazione per un determinato scenario di problema. Ad esempio, il capitolo 4 tratta di gerarchie / aggregazioni / scenari peer-to-peer, e offre quindi più progetti che si rivolgono a coloro che hanno vantaggi e svantaggi di ciascuno.

— DarrellNorton,

46

I modelli di progettazione non sono soluzioni banalmente riutilizzabili.

I modelli di progettazione sono riutilizzabili, per definizione. Sono schemi che riscontri in altre buone soluzioni.

Un modello non è banalmente riutilizzabile. Tuttavia, puoi implementare il tuo design in piuma seguendo lo schema.

Gli schemi di progettazione relazionale includono cose come:

Rapporti uno-a-molti (dettaglio principale, genitore-figlio) rapporti usando una chiave esterna.
Rapporti Many-to-Many con una tabella bridge.
Relazioni one-to-one opzionali gestite con NULL nella colonna FK.
Star-Schema: Dimension and Fact, design OLAP.
Design OLTP completamente normalizzato.
Più colonne di ricerca indicizzate in una dimensione.
"Tabella di ricerca" che contiene PK, descrizione e valori di codice utilizzati da una o più applicazioni. Perché avere il codice? Non lo so, ma quando devono essere utilizzati, questo è un modo per gestire i codici.
Uni-tavolo. [Alcuni lo definiscono un anti-schema; è uno schema, a volte è cattivo, a volte è buono.] Questo è un tavolo con molte cose pre-unite che violano la seconda e la terza forma normale.
Tavolo array. Questa è una tabella che viola la prima forma normale avendo una matrice o una sequenza di valori nelle colonne.
Database ad uso misto. Questo è un database normalizzato per l'elaborazione delle transazioni ma con molti indici extra per i report e le analisi. È un anti-pattern - non farlo. Le persone lo fanno comunque, quindi è ancora uno schema.

La maggior parte delle persone che progettano database possono facilmente scuotere una mezza dozzina di "È un altro di quelli"; questi sono modelli di progettazione che usano su base regolare.

E questo non include modelli amministrativi e operativi di utilizzo e gestione.

— S. Lott
fonte

Alcuni altri schemi che ho visto sono una tabella figlio multi-genitore (ad esempio, come una nota globale con un tipo di oggetto e un objectid che può collegarsi a qualsiasi altra tabella) o un FK autoreferenziale (cioè impiegato.manager -> impiegato. id). Inoltre ho usato una tabella di configurazione singleton che ha molte colonne.

— r00fus,

1

Perché esattamente un database ad uso misto è un anti-pattern. Cosa devo fare se desidero estrarre report da un database?

— oliva

3

@lhnz: non è possibile estrarre molti report di grandi dimensioni dalla progettazione di un database transazionale: il blocco per i report rallenterà le transazioni. I join complessi (eseguiti più e più volte) sono un altro colpo alla performance della transazione. Non puoi fare entrambi in un database. Per eseguire molti report di grandi dimensioni, è necessario spostare i dati in uno schema a stella. Lo schema a stella è ottimizzato per il reporting. E lo spostamento dei dati rimuove qualsiasi contesa di blocco.

— S.Lott

La normalizzazione dello schema ridurrebbe la contesa per il blocco delle righe se le tabelle contengono più dati "coesivi"? Il mio pensiero è che se una tabella di grandi dimensioni era in servizio scrive su 2 tipi di set di dati ma entrambi si trovano nella stessa riga, ciò comporterebbe inutili contese di blocco.

— CMCDragonkai,

6

AskTom è probabilmente la risorsa più utile per le best practice sui DB Oracle. (Di solito digito "asktom" come prima parola di una query di Google su un argomento specifico)

Non penso sia davvero appropriato parlare di modelli di progettazione con database relazionali. I database relazionali sono già l'applicazione di un "modello di progettazione" a un problema (il problema è "come rappresentare, archiviare e lavorare con i dati mantenendo la loro integrità" e la progettazione è il modello relazionale). Altri approcci (generalmente considerati obsoleti) sono i modelli di Navigazione e Gerarchici (e sono sicuro che ne esistono molti altri).

Detto questo, potresti considerare "Data Warehousing" come un "modello" o approccio un po 'separato nella progettazione del database. In particolare, potresti essere interessato a leggere sullo schema a stella .

— Galghamon
fonte

4

Dopo molti anni di sviluppo del database, posso dire che non ci sono domande e domande a cui dovresti rispondere prima di iniziare:

domande:

Vuoi utilizzare in futuro un altro DBMS? In caso affermativo, allora non utilizza oggetti speciali SQL del DBMS corrente. Rimuovi la logica dalla tua applicazione.

Non usa:

spazi bianchi nei nomi delle tabelle e delle colonne
Caratteri non Ascii nei nomi di tabelle e colonne
vincolante per una specifica minuscola o maiuscola. E non usare mai 2 tabelle o colonne che differiscono solo per le lettere minuscole e maiuscole.
non utilizza parole chiave SQL per nomi di tabelle o colonne come "DA", "TRA", "ELIMINA", ecc

Raccomandazioni:

Utilizzare NVARCHAR o equivalenti per il supporto Unicode quindi non si hanno problemi con le tabelle codici.
Assegna a ogni colonna un nome univoco. Ciò semplifica il join per selezionare la colonna. È molto difficile se ogni tabella ha una colonna "ID" o "Nome" o "Descrizione". Usa XyzID e AbcID.
Utilizzare un pacchetto di risorse o uguale a espressioni SQL complesse. Rende più semplice il passaggio a un altro DBMS.
Non esegue il cast duro su alcun tipo di dati. Un altro DBMS non può avere questo tipo di dati. Per esempio, i dae Oracle non hanno un PICCOLO solo un numero.

Spero che questo sia un buon punto di partenza.

— Horcrux7
fonte

7

Sebbene i tuoi commenti siano abbastanza istruttivi e utili, non sono modelli di progettazione. Sono le migliori pratiche. Grazie,

— Sklivvz,

7

Non sono d'accordo con la raccomandazione per nomi di colonne univoci. Preferirei che customer.id disambigua piuttosto che dire customerid anche quando non c'è nulla da disambiguare.

— Paul Tomblin,

1

La tua domanda è un po 'vaga, ma suppongo UPSERTpossa essere considerata un modello di progettazione. Per le lingue che non implementano MERGE, esistono diverse alternative per risolvere il problema (se esiste una riga adatta UPDATE,; altro INSERT).

— Sören Kuklau
fonte

UPSERT è un comando e parte del linguaggio SQL. Non è un modello.

— Todd R,

UPSERT è un comando in alcune varianti del linguaggio SQL: un certo numero di piattaforme non ce l'hanno, o l'ha ottenuto solo di recente.

— Steve Homer,

@ToddR - Ho sentito dire (leggermente cinicamente) che gli "schemi" non sono altro che carenze in un linguaggio o modello, per i quali l'utente deve creare soluzioni alternative. Non so cosa faccia UPSERT, ma mentre è stato aggiunto ad alcuni SQL e non ad altri, è uno schema.

— Martin F,

1

Dipende da cosa intendi per modello. Se stai pensando a Persona / Azienda / Transazione / Prodotto e simili, allora sì - ci sono già molti schemi di database generici disponibili.

Se stai pensando a Factory, Singleton ... allora no - non hai bisogno di nessuno di questi in quanto sono di livello troppo basso per la programmazione DB.

Se stai pensando alla denominazione degli oggetti del database, rientra nella categoria delle convenzioni, non nella progettazione in sé.

BTW, S.Lott, relazioni uno-a-molti e molti-a-molti non sono "schemi". Sono i mattoni fondamentali del modello relazionale.

— Andrea non il Santo
fonte

che dire dell'ereditarietà del database (persona, cliente, dipendente), forse quel genere di cose potrebbe essere considerato come un modello di progettazione?

— Muflix,