Sono principalmente uno sviluppatore web e ho un paio di progetti personali che voglio dare il via.
Una cosa che mi infastidisce è la progettazione del database. Ho passato la scuola alla normalizzazione del db e cose del genere ma è stato un paio di anni fa e non ho mai avuto esperienza con la progettazione di database relazionali tranne che per la scuola.
Quindi, come ti avvicini al database da una prospettiva di app web? Come inizi e cosa cerchi? Cosa sono i flag per cautela?
Il miglior libro che abbia mai acquistato per quanto riguarda la progettazione del database è stato Progettazione di database per semplici mortali di Michael Hernandez ISBN: 0-201-69471-9. Amazon Listing Ho notato che ha una terza edizione.
Ti guida attraverso l'intero processo (dall'inizio alla fine) della progettazione di un database. Ti consiglio di iniziare con questo libro.
Devi imparare a guardare le cose in gruppi o blocchi. La progettazione del database ha semplici elementi costitutivi proprio come fa la programmazione. Se acquisisci una conoscenza approfondita di questi semplici elementi costitutivi puoi affrontare qualsiasi progetto di database.
Nella programmazione hai:
Con i database hai:
Più semplice fai le cose meglio è. Un database non è altro che un luogo in cui si mettono i dati in fori di cubbie. Inizia identificando quali sono questi buchi cubbie e che tipo di cose vuoi in loro.
Non creerai mai il design perfetto del database la prima volta che proverai. Questo è un fatto. Il tuo progetto subirà diversi perfezionamenti durante il processo. A volte le cose non sembrano evidenti finché non inizi ad inserire dati, e poi hai un momento ah ha .
Il Web porta le sue serie di sfide. Problemi di Bandwith. Apolidia. Dati errati da processi che iniziano ma non vengono mai completati.
Realizzo sia la programmazione orientata agli oggetti sia la progettazione di database (per lo più transazionali, ma alcuni OLAP) e, per le mie circostanze, ci sono molti temi ricorrenti (almeno con OLTP).
Praticare la normalizzazione 3nf mi aiuta a praticare alcune varianti del principio di responsabilità singola. Una tabella dovrebbe rappresentare un concetto nel tuo sistema - e i concetti dovrebbero riguardare l'un l'altro in modo tale che tentano di imitare la realtà; per esempio, se sto costruendo un sistema in cui un cliente può avere 0 o più attività, allora creo una tabella clienti e una tabella attività. La tabella delle attività ha una relazione di chiave esterna con la tabella Cliente. Quando creo procedure memorizzate, mi assicurerei di utilizzare un join esterno per unire Cliente e attività perché il requisito aziendale che un cliente può avere attività 0.
Guardo anche a opportunità di estensibilità usando le tabelle bridge (link). Ad esempio, se cercassi di rappresentare una regola aziendale in cui un libro potesse avere un numero illimitato (variabile) di autori, creerei una tabella di libri, una tabella di autori e una tabella di bridge / link che abbia riferimenti a chiavi esterne a entrambi Libro e autore.
Inoltre, uso le chiavi surrogate su tutte le tabelle (in genere colonne di identità auto-incrementanti, ma forse Guids - il compromesso con i guids nel codice è che occupano più spazio di memoria di un intero semplice) e evito di fare affidamento sul naturale chiavi per le mie ricerche (tranne con Bridge / Link Tables). Per impostazione predefinita, creo anche indici su colonne di chiavi esterne comuni e rivedo le stored procedure / query di sistema di volta in volta per ottimizzare le strategie di indicizzazione. Un'altra strategia di indicizzazione che utilizzo è cercare i luoghi nel mio codice in cui creo una raccolta basata su una colonna di ricerca e aggiungi indici appropriati per cercare le colonne.
Per prima cosa progetto lo schema del mio database, quindi uso un ORM per creare gli oggetti da esso. Sono un po 'vecchia scuola in quel modo; Non mi fido di ORM per creare uno schema di database intelligente ed efficiente. Questo è il lavoro degli umani e parte del mestiere del software design.
Ho trovato il libro di Bill Karwin, Antipatterns SQL , per essere davvero utile per la pianificazione del database. Il punto è che il database offre molte opportunità per proteggere l'integrità e la significatività dei dati e che è un errore comune dei progettisti ignorare queste funzionalità per vari motivi allettanti. Considerare fin da subito questi problemi e far loro informare l'intero progetto è utile e batte più tardi cercando di rimediare alle incrinature.
Preferisco utilizzare un database che abbia limiti globali per applicare la logica e l'integrità aziendale a livello di database. Spesso vedo il database come l'applicazione e tutto ciò che lo accede come una semplice interfaccia. Ciò rende l'aggiunta di altre "interfacce" un'esperienza più piacevole e diretta e offre vantaggi positivi per la sicurezza.
Penso anche che sia importante considerare la struttura del database come un'entità che cambia, piuttosto che assumere che sia necessario avvolgerlo e sigillarlo prima di iniziare qualsiasi altra cosa. È necessario pianificare la modifica e accettare il DB nel proprio sistema di controllo delle versioni. C'è un bel saggio su questo: Progetto di database evolutivo di Martin Fowler & Pramod Sadalage (e anche un intero libro sull'argomento di Sadalage, anche se non l'ho letto).
Infine, i problemi periferici di account / ruoli utente, hardware / posizione / connessione dell'host, ecc. sono importanti e talvolta trascurati. Tienilo presente anche quando pianifichi.
la progettazione del database non può essere eseguita completamente senza considerare come verranno utilizzati i dati, quindi ecco un breve elenco di passaggi:
Per progettare correttamente un database è necessario considerare prima alcune cose:
Quindi, prima di iniziare a progettare un database, è necessario prima conoscere la normalizzazione e le funzionalità di un database utilizzato per mantenere l'integrità dei dati.
Quindi devi capire l'ottimizzazione delle prestazioni. Questo non è prematuro, le prestazioni sono il punto critico di fallimento della maggior parte dei database ed è molto difficile da risolvere una volta che hai milioni di record.
Infine, è necessario capire come proteggere i dati e quali dati devono essere protetti e quali controlli interni sono necessari per garantire che i dati non siano modificati maliziosamente o per assicurarsi di poter monitorare i cambiamenti nel tempo per scoprire chi e quando è stata apportata una modifica e poter tornare alle versioni precedenti.
È anche utile leggere un po 'sul refactoring dei database prima di iniziare, poiché in seguito sarà necessario eseguire il refactoring e sarà utile sapere come impostare le cose in modo da poter effettuare il refactoring il più facilmente possibile.
In generale i dati sopravvivono all'applicazione da molti anni, è il cuore dell'applicazione e non devono essere considerati come un archivio dati stupido che è per lo più irrilevante.
In termini generali, una buona progettazione del database è un buon progetto di database: la più grande domanda per l'uso del web sarà il modo in cui accedete ai dati e gestite le cose che uno potrebbe prendere in considerazione richiedono essenzialmente che il web non ha.
Pensandoci su, il mio approccio si basa su un bel po 'di esperienza ... ma se inizi con lo schema o gli oggetti stai provando a fare la stessa cosa, cioè costruisci un modello utilizzabile dei tuoi dati - per un un numero considerevole di progetti potrebbe essere una relazione abbastanza diretta tra modello e schema (non in tutti i casi, e probabilmente non per tutte le tabelle / oggetti) quindi è davvero una questione di costruire un modello decente iniziando dove sei a tuo agio e lavorando da lì.
In termini di costruzione di un modello decente - @Tim lo ha per i database e fondamentalmente per costruire il tuo modello di oggetti sarà molto simile - cos'è unico, cos'è una gerarchia, dove ci sono molte e molte relazioni, ecc. quindi , comunque si arriva a un database, assicurarsi di fare tutte le cose buone.
Assicurati anche di avere script o ddl in codice per permetterti di creare lo schema da zero e di aggiornarlo mentre apporti le modifiche (ddl in codice è il mio metodo preferito - ho un sistema e funziona).
Comincio con una grande lavagna e un mucchio di colori diversi di penna. Colori diversi significano cose diverse. E ho appena iniziato a disegnare. Di solito disegno cose che sono definite in nero, cose che sono probabilmente in blu e cose che sono improbabili in verde. Il rosso è per le note importanti. Cancello e ridisegno copiosamente. Penso a che tipo di cose ho bisogno di interrogare e mi assicuro che il modello lo supporti. In caso contrario, modificherò fino a quando non lo farà.
Alla fine, se il modello diventa troppo grande, lo sposterò su Visio e lavorerò sui pezzi sulla lavagna.
L'ultima volta penso ai punti di estensione. L'errore più grande che vedo la maggior parte delle persone è quello di progettare il proprio database e quindi dire "Ho finito con il database" e andare avanti. Non hai mai finito con il database. È probabile che ogni singola richiesta di modifica venga portata fino a quel livello. Quindi pensa a come aggiungerlo. Pensa a quali tipi di richieste sono probabili e vedi se riesci ad agganciarle. Se non pensi affatto all'estensibilità, entrerai in debito di progettazione quando queste cambiano richieste.
Come per "SQL then ORM" o viceversa, dipende da voi. Assicurati solo che il tuo modello faccia una buona base per prima.
Per prima cosa disegno gli oggetti quindi utilizzo un ORM (come nibernate) per creare lo schema. Mi dà molta più flessibilità di fare l'inverso.
Il prossimo passo è l'ottimizzazione dello schema generato.
È passato molto tempo da quando ho visto un progetto in cui le tabelle del database sono state progettate per prime.
Poche cose non esplicitamente dichiarate finora da altri utenti:
È meglio avere la progettazione del database fatta da qualcuno che è professionale. Ovviamente è ovvio apprendere, ma non suggerirei di costruire un modello medio o grande se non si è esperti in modellazione o progettazione di database. La ragione di ciò è che il costo di un disegno sbagliato è solitamente molto alto.
Conoscere bene gli obiettivi del sistema e le esigenze degli utenti. Senza conoscere i requisiti, non è possibile progettare il modello dati corretto.
Conoscere quale codice fare nei programmi e quale codice consentire al DB di occuparsi di. Questo è necessario per impostare correttamente la colonna di dati null, not null, ecc. Questo è richiesto anche per specificare correttamente il RI.
Determina bene le tue chiavi primarie. Vai per le chiavi semplici quando puoi.
Considera esigenze di integrazione con altre applicazioni.
Prendi in considerazione l'utilizzo di modelli di dati universali e segui gli standard del settore nella denominazione e nella dimensione della colonna di dati.
Pensa ai bisogni futuri (quando conosciuti e quando applicabile)
Fai rivedere la tua modalità da altri.
Utilizza uno strumento per la modellazione: uno strumento ERD o uno strumento UML.
Verifica e comprendi il codice DDL generato. Non dare per scontato.
Leggi altre domande sui tag database-design learning