20
Mi piacerebbe sapere dai programmatori esperti quali considerano le considerazioni più importanti quando si progetta un nuovo database.Quali sono le considerazioni più importanti quando si progetta un database?
A
risposta
20
Prima di tutto e più importante imparare e comprendere il dominio aziendale.
1) stai guardando un alto tasso di transazione come un sito web occupato, o basso utilizzo come aa piccola azienda sistema HR
2) È la sicurezza un grande problema - stai gestendo dati personali o dati finanziari . O è solo un catalogo di prodotti
3) Saranno gli utenti essere facendo molti aggiornamenti/inserti o è principalmente di sola lettura
4) il numero di utenti, quali sono i modelli di utilizzo (carico di punta o uniformemente distribuito)
5) avete bisogno di 24x7, 16x5 o altro uptime, 24x7 è molto più difficile da fare come non avete tempo per manutenzione
6) quanto è grande il DB sta per andare? Se è veramente grande si dovrà progettare le tabelle per tener conto di questo e/o partizione
7) Avete bisogno di guardare enterprise cluster con caldo il failover, o semplicemente normale che ospita
8) Come sarà il DB ammesso, nella maggior parte dei progetti DB il 95% dello sforzo viene speso per lo sviluppo degli utenti e delle loro applicazioni, l'amministratore del DB è dimenticato
9) DB Admin, dal precedente include backup, modifiche ad altri sistemi, integrazione ad altri sistemi, caricamento dei dati
10) In realtà il caricamento dei dati e l'utilizzo dei dati esistenti è un altro g problema a sé stante.
Questo è tutto per un inizio
5
Fidelity con le entità del mondo reale che il database dovrebbe modellare.
+0
+1 se non ce l'hai, avrai un disastro che non funzionerà mai. –
4
Personalmente suggerirei di prendere o prendere in prestito una copia di "Database Design for Mere Mortals". Tutto ciò che avresti sempre bisogno di prendere in considerazione nella progettazione di un database sarebbe elencato in quel libro, ed è in un ordine molto metodico e logico in cui puoi costruire il database. Le definizioni di tabella e colonna sono noiose, ma alla fine vale ogni minuto.
Credo che potresti essere in grado di leggere il primo capitolo del libro tramite Google Libri o tramite l'anteprima della pagina su Amazon.com.
Ci sono alcune curiosità che puoi imparare nel tempo o da questo sito come "best practice", ma non c'è niente di meglio che progettarlo da zero nel modo corretto al primo tentativo.
14
Il database è secondario per il vostro disegno dei processi di business e deve in modo pulito supportare il processo di business in modo diretto e semplice. Otterrete molto più beneficio da un modello di entità ben formato e pulito rispetto a un indice qua e là. Quindi, una volta definito il processo, lo prendi e lo dividi in "entità" nel modo più pulito possibile con le relazioni che hanno senso. Una volta che conosci le tue entità, esse si traducono in tabelle di database.
Una delle cose più importanti da fare è non sovradimensionare.
Per dare una risposta con alcuni denti, prendiamo come esempio un'entità "veicolo". Un veicolo ha più ruote. Hai una decisione critica da fare sapere che ci saranno più ruote attaccate al veicolo. Hai 2 scelte da fare: puoi rendere le "ruote" un'entità separata, oppure puoi fare "numero di ruote" un campo intero nell'entità "Veicolo".
Se il numero di telefono è assolutamente noto a, sarà necessario memorizzare molte informazioni modificabili su ciascuna ruota, quindi creare un'entità "Ruota". Ora hai una relazione tra entità (la macchina e la ruota).
In caso contrario, un campo semplice andrà bene.
Pensare attraverso queste decisioni critiche e rendere le cose il più semplici possibile è di gran lunga la cosa più importante per me quando si progetta un database. Può fare la differenza tra le cose che sono davvero facili e davvero difficili quando si costruiscono i livelli successivi della propria applicazione.
1
Un set di base di punti:
- Determinare lo scopo del vostro sistema.
- Identificare le entità necessarie per il sistema.
- Identificare le informazioni che ciascuna entità deve fornire.
- Identificare le relazioni esistenti tra le entità
- Che cosa vorrebbe sapere l'utente e fare con i dati.
- concettuale e logica Database Design
- Normalizzazione e ERD
- Identificare i campi con valori univoci.
- Selezionare i tipi di dati appropriati per i campi.
- Rifacimento database.
1
devi anche capire per che cosa verrà utilizzato il database. se è per le transazioni (OLTP), dovrebbe essere il più possibile normalizzato e l'obiettivo è completare le transazioni il più rapidamente possibile. se è per analisi e/o reporting (OLAP), dovrebbe essere denormalizzato in molti luoghi dove si eseguirà l'aggregazione. le considerazioni sulla progettazione per i database OLTP non sono applicabili ai database OLAP e viceversa.
2
Conosci i tuoi dati.
1
chi lo costruirà e lo manterrà, dove, come e con cosa. Avete metodi e procedure e procedimenti per fare questo o semplicemente volarlo. Certamente le esigenze aziendali guidano i dati necessari che dovrebbero essere catturati in un ERD indipendente dall'implementazione. Ma devi anche pensare a chi manterrà i dati nel tempo. Così come chi "possiede" i dati. Chi possiede le definizioni di entità e attributo.
1
I requisiti di informazione sono la parte più importante.
Questo è un altro modo per dire "determinare lo scopo del proprio sistema", da una risposta fornita da CMS.
La modellazione concettuale dei dati è solo un modo organizzato di raccogliere e presentare i requisiti di informazione.Ogni valore memorizzato e pubblicato dal database è collegato a un attributo e ogni attributo a un dominio. Gli attributi, a loro volta, descrivono le entità o le relazioni tra entità. Oggetto Le entità e le relazioni costituiscono la struttura concettuale del "mondo reale" che i dati descrivono. Costruire un ERD da un modello concettuale è facile, anche se noioso.
Successivamente, è possibile selezionare un DBMS, progettare il database logico, progettare il database fisico e creare. Ad ogni passo, le decisioni che prendi sono più reversibili, a causa dell'indipendenza dei dati. L'indipendenza dei dati incapsula le decisioni di progettazione all'interno del database, ad eccezione delle conseguenze sulle prestazioni. Devi conoscere il tuo strumento, ovviamente.
Avere uno strumento per gestire i modelli e convertirli in diagrammi e script può essere molto utile per velocizzare questo processo e ridurre gli errori.
Ma se si verificano errori gravi o omissioni nei propri requisiti informativi, nessuna quantità di progettazione o implementazione intelligente può compensare tale problema.
7
1 - Coerenza
Nel corso del tempo il database cambierà e altre persone sarà necessario lavorare con esso. Fai un favore a te stesso ea loro e assicurati che le strutture siano nominate in modo tale che ogni persona ragionevole con conoscenza di base del dominio sarà in grado di anticipare il contenuto della tabella. Prendi il tempo di scrivere (potrebbe essere un semplice blocco note) alcuni costrutti di base che usi.
Esempi:
tasti- primarie iniziano tutti con IdTableName
- Cassa di nomi di tabella è Pascal
- chiavi esterne sono tutti TableNameId
- ext ...
Sia che scegliere di utilizzare caratteri di sottolineatura o no (sostituisci qualsiasi altra conversione per caratteri di sottolineatura) non ha molta importanza alla fine della giornata ong come sei coerente nel modo in cui usi o non li usi.
Il database è l'ultima linea di difesa per l'integrità dei dati. Tutti i tuoi dati accedono attraverso stored procedure e impongono l'integrità dei dati utilizzando vincoli di controllo, chiavi esterne e così via. Digitare i dati correttamente, non utilizzare VARCHAR (50) quando CHAR (5) è più specifico e preciso.
Qualcun altro ha accennato a mantenerlo semplice. Ultimo ma non meno importante non costruire qualcosa perché "pensi" ne avrai bisogno il prossimo mese. Le cose cambiano rapidamente e finirai per fare più manutenzione su cose che hai pensato che avresti usato piuttosto che su cose che stai usando se riempirai il tuo database, roba che non serve a nulla.
1
Una buona base di dati può essere giudicata come segue:
Se un database è stato progettato correttamente, si dovrebbe essere in grado di capire come un business funziona, cercando in niente di più allora lo schema.
In altre parole, la banca dati è l'azienda. Se il database non riflette il modo in cui viene eseguita l'attività, il database è sbagliato o il business è sbagliato.
Il database è anche una delle poche cose che davvero, davvero bisogno di inchiodare in anticipo. È sempre possibile correggere il codice errato, ma raramente si può uscire da una cattiva modifica dello schema. Assicurati di farlo bene.
0
- Convenzioni di denominazione: attenersi a una serie di regole
- normalizzazione: (misura di normalizzazione) - questo dipenderà dal numero di leggere vs numero di confronto aggiornamenti di un'entità di dati.
- Integrità relazionale e altri vincoli: alcune persone sostengono l'uso delle chiavi esterne mentre altre no, ma è necessario sceglierlo in base alle proprie esigenze e alle proprie preferenze personali poiché è un grande dibattito ma sceglierei sempre utilizzare FK
- Creare diagrammi di database, analizzare e discutere con il team, se possibile.
Sicurezza, prestazioni, disponibilità ... ma l'integrità dei dati e la modellazione accurata dell'UoD non rendono nemmeno le tue 10 "cose più importanti" :( – sqlvogel
+1 molto utile grazie – Anthony