Come affronti la progettazione di database? [chiuso]

Sono principalmente uno sviluppatore web e ho un paio di progetti personali che voglio dare il via.

Una cosa che mi infastidisce è la progettazione di database. Ho attraversato la normalizzazione del database scolastico e cose del genere, ma è stato un paio di anni fa e non ho mai avuto esperienza con la progettazione di database relazionali, tranne per la scuola.

Quindi, come affronti il ​​database dal punto di vista dell'app Web? Come inizi e cosa cerchi? Quali sono le bandiere di cautela?

Il miglior libro che abbia mai acquistato in merito alla progettazione di database è stato Database Design for Mere Mortals di Michael Hernandez ISBN: 0-201-69471-9. Elenco Amazon Ho notato che ha una terza edizione.

Link alla terza edizione

Ti guida attraverso l'intero processo di (dall'inizio alla fine) di progettazione di un database. Ti consiglio di iniziare con questo libro.

Devi imparare a guardare le cose in gruppi o pezzi. La progettazione del database ha semplici elementi costitutivi proprio come la programmazione. Se acquisisci una conoscenza approfondita di questi semplici elementi costitutivi, puoi affrontare qualsiasi progetto di database.

Nella programmazione hai:

• Se costruisce
• Se altro costruisce
• Fare mentre loop
• Do Until Loops
• Costrutti di caso

Con i database hai:

• Tabelle dati
• Tabelle di ricerca
• Relazioni individuali
• Uno a molti rapporti
• Rapporti da molti a molti
• Chiavi primarie
• Chiavi esterne

Più semplice rendi le cose migliori. Un database non è altro che un luogo in cui inserire i dati in buchi nascosti. Inizia identificando cosa sono questi buchi e quali tipi di cose che vuoi in loro.

Non hai mai intenzione di creare il perfetto design del database la prima volta che provi. Questo è un fatto. Il tuo design subirà diversi perfezionamenti durante il processo. A volte le cose non sembrano evidenti fino a quando non si inizia a inserire i dati e quindi si ha un momento ah ah .

Il web porta le proprie sfide. Problemi con la banda. Apolidia. Dati errati provenienti da processi che iniziano ma non finiscono mai.

Faccio sia programmazione orientata agli oggetti sia progettazione di database (principalmente transazionali, ma alcuni OLAP) e, per le mie circostanze, ci sono molti temi ricorrenti (almeno con OLTP).

La pratica della normalizzazione 3nf mi aiuta a praticare alcune varianti del principio della responsabilità singola. Una tabella dovrebbe rappresentare un concetto nel tuo sistema - e i concetti dovrebbero essere correlati tra loro in modo tale da tentare di imitare la realtà; ad esempio, se sto creando 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 del cliente. Quando creo le procedure memorizzate, mi assicurerei di utilizzare un join esterno per unire il cliente e l'attività perché il requisito aziendale che un cliente può avere 0 attività.

Guardo anche le opportunità di estensibilità usando le tabelle bridge (link). Ad esempio, se cercassi di rappresentare una regola aziendale in cui un libro potrebbe avere un numero illimitato (variabile) di autori, creerei una tabella di libri, una tabella di autori e una tabella bridge / link con riferimenti di chiave esterna a entrambi Libro e autore.

Inoltre, utilizzo le chiavi surrogate su tutte le tabelle (in genere colonne con identità a incremento automatico, ma forse le Guide - il compromesso con le guide nel codice è che occupano più spazio di memoria di un semplice numero intero), ed evito di fare affidamento su chiavi naturali per il mio ricerche (tranne con le tabelle Bridge / Link). Per impostazione predefinita, creo anche indici su colonne di chiavi esterne comuni e rivedo periodicamente le stored procedure / query di sistema per ottimizzare le strategie di indicizzazione. Un'altra strategia di indicizzazione che uso è quella di cercare luoghi nel mio codice in cui creo una raccolta basata su una colonna di ricerca e aggiungere indici appropriati alle colonne di ricerca.

Progetto prima il mio schema di database, quindi uso un ORM per creare gli oggetti da esso. Sono un po 'vecchia scuola in quel modo; Non mi fido degli ORM per creare uno schema di database intelligente ed efficiente. Questo è il lavoro degli umani e parte del mestiere di progettazione del software.

Ho trovato il libro di Bill Karwin, SQL Antipatterns , davvero utile per la pianificazione del database. Il punto più comprensibile è 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 questi problemi fin dall'inizio e lasciarli informare l'intero progetto è utile e batte cercando di incartare le crepe in un secondo momento.

Preferisco utilizzare un database con vincoli globali per applicare la logica e l'integrità aziendali a livello di database. Spesso vedo il database come l'applicazione e tutto ciò che vi accede come una semplice interfaccia. Ciò rende l'aggiunta di altre "interfacce" un'esperienza più piacevole e diretta e presenta vantaggi positivi per la sicurezza.

Penso anche che sia importante considerare la struttura del database come un'entità che cambia, piuttosto che supporre che sia necessario avvolgerlo e sigillarlo prima di iniziare qualsiasi altra cosa. È necessario pianificare le modifiche e accogliere il DB nel proprio sistema di controllo delle versioni. C'è un bel saggio su questo: Evolutionary Database Design di Martin Fowler e 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. Tienili a mente anche durante la pianificazione.

la progettazione del database non può essere eseguita completamente senza considerare come verranno utilizzati i dati, quindi ecco un breve elenco di passaggi:

• scrivere brevi frasi catturando la relazione tra entità
• disegna un diagramma entità-relazione che rappresenta le frasi
• creare un modello di dati logici normalizzato dal diagramma ER
• creare una matrice CRUD per applicazioni ed entità
• utilizzare la matrice per verificare la copertura del ciclo di vita di ciascuna entità
• estrarre sottoscasi per ogni applicazione
• esaminare i percorsi di navigazione sui sottoschemi per ogni operazione principale / CRUD
• considerare i report che saranno richiesti
• progettare il modello di dati fisici basato su tutto quanto sopra; denormalizzare, partizionare e utilizzare gli schemi a stella ove appropriato

Per progettare con successo un database devi prima considerare diverse cose:

• Quali dati devo archiviare e in che modo sono correlati agli altri dati che conservo. In che modo questi dati dovranno cambiare nel tempo? Devo essere in grado di vedere un'istantanea in tempo (quell'ordine dal 2009) o ho bisogno solo di ciò che è attuale (solo utenti attivi)?
• Come posso assicurarmi che i miei dati siano significativi e mantengano il significato nel tempo (integrità dei dati)?
• Come posso assicurarmi che l'accesso ai dati sia veloce?
• Come posso proteggere i miei dati?

Quindi, prima di iniziare a progettare un database, è necessario innanzitutto conoscere la normalizzazione e le funzionalità di un database utilizzato per mantenere l'integrità dei dati.

Quindi è necessario comprendere l'ottimizzazione delle prestazioni. Questo non è prematuro, le prestazioni sono il punto critico di errore della maggior parte dei database ed è molto difficile da correggere dopo aver ottenuto milioni di record.

Infine, è necessario comprendere come proteggere i dati e quali dati devono essere protetti e quali controlli interni sono necessari per garantire che i dati non vengano modificati in modo dannoso o per essere in grado di tenere traccia delle modifiche nel tempo per scoprire chi e quando è stata apportata una modifica e per poter tornare alle versioni precedenti.

È anche utile leggere un po 'di refactoring sui database prima di iniziare, poiché sarà necessario eseguire il refactoring in un secondo momento ed è utile sapere come impostare le cose in modo da poter effettuare il refactoring il più facilmente possibile.

In generale, i dati sopravvivono all'applicazione per 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 è una buona progettazione del database: la domanda più grande per l'uso del Web sarà come accedere ai dati e gestire le cose che si potrebbe considerare richiedono lo stato che sostanzialmente il web non ha.

Pensandoci, il mio approccio si basa su molta esperienza piuttosto ... ma se inizi con lo schema o gli oggetti stai effettivamente cercando di fare la stessa cosa, cioè costruire un modello utilizzabile dei tuoi dati - per un numero sostanziale di è probabile che ci sia 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 a partire da qualsiasi luogo a tuo agio e lavorare da lì.

In termini di costruzione di un modello decente - @Tim ce l'ha per down per i database e fondamentalmente costruire il tuo modello a oggetti sarà sostanzialmente simile - ciò che è unico, ciò che è una gerarchia, dove ci sono molte o molte relazioni, ecc. accedere a un database, assicurarsi di fare tutte le cose buone.

Assicurati anche di avere script o ddl nel codice per permetterti di creare lo schema da zero e di aggiornarlo mentre apporti delle modifiche (ddl nel codice è il mio metodo preferito - ho un sistema e funziona).

Comincio con una grande lavagna e un mucchio di diversi colori di penna. Colori diversi significano cose diverse. E ho appena iniziato a disegnare. Di solito disegno cose definite in nero, cose che sono probabilmente in blu e cose che sono improbabili in verde. Il rosso è per le note importanti. Cancella e ridisegno copiosamente. Penso a quali tipi di cose ho bisogno di interrogare e assicurarmi 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.

Infine, penso ai punti di estensione. L'errore più grande che vedo fare alla maggior parte delle persone è progettare il loro database e poi dire "Ho finito con il database" e andare avanti. Non hai mai finito con il database. È probabile che ogni singola richiesta di modifica arrivi fino a quel livello. Quindi pensa a come aggiungerlo. Pensa a quali tipi di richieste sono probabili e vedi se sei in grado di agganciarle. Se non pensi affatto all'estensibilità, andrai in debito con il design quando queste richieste di cambiamento emergono.

Per quanto riguarda "SQL then ORM" o viceversa, dipende da te. Assicurati solo che il tuo modello costituisca prima una buona base.

Prima progetto oggetti, quindi uso un ORM (come nHibernate) per creare lo schema. Mi dà molta più flessibilità che fare l'inverso.

Il prossimo passo è l'ottimizzazione dello schema generato.

È da molto tempo che non vedo un progetto in cui le tabelle del database sono state progettate per prime.

Poche cose non espressamente dichiarate finora da altri compagni:

• È meglio che la progettazione del database sia eseguita da qualcuno che è professionale. Va bene imparare ovviamente, ma non suggerirei di costruire un modello medio o grande se non si è ben versati nella modellazione o nella progettazione di database. La ragione di ciò è che il costo di una progettazione errata è generalmente molto elevato.

• Conoscere bene gli obiettivi di sistema e i requisiti dell'utente. Senza conoscere i requisiti non è possibile progettare il modello di dati corretto.

• Sapere quale codice fare nei programmi e quale codice far gestire al DB. Ciò è necessario per impostare correttamente la colonna di dati null, non null, ecc. Ciò è necessario anche per specificare correttamente il proprio RI.

• Determina bene le tue chiavi primarie. Scegli chiavi semplici quando puoi.

• Considerare le 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 applicabili)

• Fai rivedere la tua modalità da altri.

• Utilizzare uno strumento per la modellazione: uno strumento ERD o uno UML.

• Revisionare e comprendere il codice DDL generato. Non dare per scontato.