Che ci piaccia o no, molti, se non la maggior parte di noi sviluppatori, lavorano regolarmente con i database o potrebbero dover lavorare con uno un giorno. E considerando la quantità di uso improprio e abuso in natura e il volume di domande relative al database che sorgono ogni giorno, è giusto dire che ci sono alcuni concetti che gli sviluppatori dovrebbero conoscere, anche se non progettano o lavorano con database oggi. Così:

Quali sono i concetti importanti che gli sviluppatori e altri professionisti del software dovrebbero conoscere sui database?

Linee guida per le risposte:

Mantieni breve la tua lista.
Un concetto per risposta è il migliore.

Sii specifico .
La "modellazione dei dati" può essere un'abilità importante , ma cosa significa esattamente?

Spiega la tua logica.
Perché il tuo concetto è importante? Non limitarti a dire "usa gli indici". Non cadere nelle "migliori pratiche". Convinci il tuo pubblico a saperne di più.

Dai un voto positivo alle risposte con cui sei d'accordo.
Leggi prima le risposte degli altri. Una risposta di alto rango è un'affermazione più efficace di due risposte di basso rango. Se hai altro da aggiungere, aggiungi un commento o fai riferimento all'originale.

Non sottovalutare qualcosa solo perché non si applica a te personalmente.
Lavoriamo tutti in domini diversi. L'obiettivo in questo caso è fornire indicazioni ai neofiti del database per acquisire una comprensione ben fondata e completa della progettazione del database e dello sviluppo basato sul database, non per competere per il titolo di più importante.

La prima cosa che gli sviluppatori dovrebbero sapere sui database è questa: a cosa servono i database ? Non come funzionano, né come si costruisce uno, né come si scrive il codice per recuperare o aggiornare i dati in un database. Ma a cosa servono?

Sfortunatamente, la risposta a questa domanda è un bersaglio mobile. All'apice dei database, dagli anni '70 fino all'inizio degli anni '90, i database erano destinati alla condivisione dei dati. Se stavi usando un database e non stavi condividendo dati o eri coinvolto in un progetto accademico o stavi sprecando risorse, incluso te stesso. La creazione di un database e l'addomesticamento di un DBMS erano compiti così monumentali che il rimborso, in termini di dati sfruttati più volte, doveva essere enorme per corrispondere all'investimento.

Negli ultimi 15 anni, i database sono stati utilizzati per archiviare i dati persistenti associati a una sola applicazione. La creazione di un database per MySQL , Access o SQL Server è diventata così routine che i database sono diventati quasi una parte di routine di una normale applicazione. A volte, quella missione limitata iniziale viene spinta verso l'alto dal creep della missione, quando il valore reale dei dati diventa evidente. Sfortunatamente, i database progettati con un unico scopo in mente spesso falliscono in modo drammatico quando iniziano a essere inseriti in un ruolo che è a livello aziendale e mission-critical.

La seconda cosa che gli sviluppatori devono imparare sui database è l'intera visione del mondo incentrata sui dati . La visione del mondo incentrata sui dati è più diversa dalla visione del mondo incentrata sui processi di quanto la maggior parte degli sviluppatori abbia mai imparato. Rispetto a questo divario, il divario tra programmazione strutturata e programmazione orientata agli oggetti è relativamente piccolo.

La terza cosa che gli sviluppatori devono imparare, almeno in una panoramica, è la modellazione dei dati, inclusa la modellazione dei dati concettuali, la modellazione logica dei dati e la modellazione fisica dei dati.

La modellazione concettuale dei dati è davvero un'analisi dei requisiti da un punto di vista incentrato sui dati.

La modellazione dei dati logici è generalmente l'applicazione di un modello di dati specifico ai requisiti scoperti nella modellazione dei dati concettuali. Il modello relazionale viene utilizzato molto più di qualsiasi altro modello specifico e gli sviluppatori devono sicuramente imparare il modello relazionale. Progettare un modello relazionale potente e pertinente per un requisito non banale non è un compito banale. Non è possibile creare buone tabelle SQL se si fraintende il modello relazionale.

La modellazione fisica dei dati è generalmente specifica per DBMS e non ha bisogno di essere appresa in dettaglio, a meno che lo sviluppatore non sia anche il costruttore del database o il DBA. Ciò che gli sviluppatori devono capire è la misura in cui la progettazione fisica del database può essere separata dalla progettazione logica del database e la misura in cui la produzione di un database ad alta velocità può essere realizzata semplicemente modificando la progettazione fisica.

La prossima cosa che gli sviluppatori devono imparare è che mentre la velocità (prestazioni) è importante, altre misure di bontà del design sono ancora più importanti , come la capacità di rivedere ed estendere l'ambito del database lungo la strada, o la semplicità della programmazione.

Infine, chiunque giochi con i database deve capire che il valore dei dati spesso supera il sistema che li ha acquisiti .

Whew!

Buona domanda. Di seguito sono riportati alcuni pensieri senza un ordine particolare:

1. La normalizzazione, almeno alla seconda forma normale, è essenziale.

2. Anche l'integrità referenziale è essenziale, con adeguate considerazioni sull'eliminazione e l'aggiornamento a cascata.

3. Uso buono e corretto dei vincoli di controllo. Lascia che il database lavori il più possibile.

4. Non disperdere la logica aziendale sia nel database che nel codice di livello intermedio. Scegli uno o l'altro, preferibilmente nel codice di livello intermedio.

5. Decidi un approccio coerente per le chiavi primarie e le chiavi cluster.

6. Non esagerare con l'indicizzazione. Scegli i tuoi indici con saggezza.

7. Denominazione coerente di tabelle e colonne. Scegli uno standard e rispettalo.

8. Limita il numero di colonne nel database che accetteranno valori null.

9. Non lasciarti trasportare dai trigger. Hanno il loro uso ma possono complicare le cose in fretta.

10. Fai attenzione con le UDF. Sono ottimi ma possono causare problemi di prestazioni se non si è consapevoli della frequenza con cui potrebbero essere chiamati in una query.

11. Ottieni il libro di Celko sulla progettazione di database. L'uomo è arrogante ma sa il fatto suo.

Innanzitutto, gli sviluppatori devono capire che c'è qualcosa da sapere sui database. Non sono solo dispositivi magici in cui inserisci l'SQL e ottieni set di risultati, ma piuttosto pezzi di software molto complicati con la loro logica e stranezze.

In secondo luogo, che ci sono diverse configurazioni di database per scopi diversi. Non vuoi che uno sviluppatore esegua rapporti storici da un database transazionale in linea se è disponibile un data warehouse.

In terzo luogo, gli sviluppatori devono comprendere l'SQL di base, inclusi i join.

Oltre a ciò, dipende da quanto sono coinvolti gli sviluppatori. Ho lavorato in lavori in cui ero sviluppatore e de facto DBA, dove gli amministratori di database erano appena in fondo al corridoio e dove gli amministratori di database sono nella loro area. (Non mi piace il terzo.) Supponendo che gli sviluppatori siano coinvolti nella progettazione del database:

Devono comprendere la normalizzazione di base, almeno le prime tre forme normali. Qualunque cosa oltre a questo, ottieni un DBA. Per coloro che hanno esperienza con i tribunali statunitensi (e qui contano programmi televisivi casuali), c'è lo mnemonico "Dipende dalla chiave, l'intera chiave e nient'altro che la chiave, quindi aiutati Codd".

Devono avere un indizio sugli indici, con questo intendo che dovrebbero avere un'idea di quali indici hanno bisogno e come possono influenzare le prestazioni. Ciò significa non avere indici inutili, ma non aver paura di aggiungerli per facilitare le query. Qualunque altra cosa (come l'equilibrio) dovrebbe essere lasciata al DBA.

Devono comprendere la necessità di integrità dei dati ed essere in grado di indicare dove stanno verificando i dati e cosa stanno facendo in caso di problemi. Questo non deve essere nel database (dove sarà difficile emettere un messaggio di errore significativo per l'utente), ma deve essere da qualche parte.

Dovrebbero avere le conoscenze di base su come ottenere un piano e come leggerlo in generale (almeno quanto basta per dire se gli algoritmi sono efficienti o meno).

Dovrebbero sapere vagamente cos'è un trigger, cos'è una vista e che è possibile partizionare parti di database. Non hanno bisogno di alcun tipo di dettagli, ma hanno bisogno di sapere per chiedere al DBA di queste cose.

Ovviamente dovrebbero sapere di non intromettersi con i dati di produzione, o il codice di produzione, o qualcosa del genere, e dovrebbero sapere che tutto il codice sorgente va in un VCS.

Senza dubbio ho dimenticato qualcosa, ma lo sviluppatore medio non deve essere un DBA, a condizione che ci sia un vero DBA a portata di mano.

Indicizzazione di base

Sono sempre scioccato nel vedere una tabella o un intero database senza indici o indici arbitrari / inutili. Anche se non stai progettando il database e devi solo scrivere alcune query, è comunque fondamentale capire, come minimo:

• Cosa è indicizzato nel tuo database e cosa no:
• La differenza tra i tipi di scansioni, il modo in cui vengono scelti e il modo in cui scrivi una query possono influenzare tale scelta;
• Il concetto di copertura (perché non dovresti semplicemente scrivere SELECT *);
• La differenza tra un indice cluster e non cluster;
• Perché gli indici più / più grandi non sono necessariamente migliori;
• Perché dovresti cercare di evitare di racchiudere le colonne del filtro in functions.

I progettisti dovrebbero anche essere consapevoli dei comuni anti-pattern di indice, ad esempio:

• L'anti-pattern di accesso (indicizzazione di ogni colonna, una per una)
• L'anti-pattern Catch-All (un enorme indice su tutte o la maggior parte delle colonne, apparentemente creato con l'errata impressione che velocizzerebbe ogni immaginabile query che coinvolge una qualsiasi di quelle colonne).

La qualità dell'indicizzazione di un database - e se ne approfitti o meno con le query che scrivi - rappresenta di gran lunga la parte più significativa delle prestazioni. 9 domande su 10 pubblicate su SO e altri forum che lamentano prestazioni scadenti risultano invariabilmente dovute a una scarsa indicizzazione o ad un'espressione non selezionabile.

Normalizzazione

Mi deprime sempre vedere qualcuno che fatica a scrivere una query eccessivamente complicata che sarebbe stata completamente semplice con un design normalizzato ("Mostrami le vendite totali per regione").

Se lo capisci all'inizio e progetti di conseguenza, ti risparmierai molto dolore in seguito. È facile denormalizzare per le prestazioni dopo la normalizzazione; non è così facile normalizzare un database che non è stato progettato in questo modo dall'inizio.

Per lo meno, dovresti sapere cos'è 3NF e come arrivarci. Con la maggior parte dei database transazionali, questo è un ottimo equilibrio tra rendere le query facili da scrivere e mantenere buone prestazioni.

Come funzionano gli indici

Probabilmente non è l'argomento più importante, ma sicuramente quello più sottovalutato.

Il problema con l'indicizzazione è che i tutorial SQL di solito non li menzionano affatto e che tutti gli esempi di giocattoli funzionano senza alcun indice.

Anche gli sviluppatori più esperti possono scrivere SQL abbastanza buono (e complesso) senza saperne di più sugli indici di " Un indice rende veloce la query ".

Questo perché i database SQL fanno un ottimo lavoro lavorando come scatola nera:

Dimmi di cosa hai bisogno (dammi SQL), ci penso io.

E funziona perfettamente per recuperare i risultati corretti. L'autore dell'SQL non ha bisogno di sapere cosa sta facendo il sistema dietro le quinte - fino a quando tutto diventa così slooooow .....

È allora che l'indicizzazione diventa un argomento. Ma di solito è molto tardi e qualcuno (qualche azienda?) Sta già soffrendo di un vero problema.

Ecco perché credo che l'indicizzazione sia l'argomento n. 1 da non dimenticare quando si lavora con i database . Purtroppo è molto facile dimenticarlo.

Disclaimer

Gli argomenti sono presi in prestito dalla prefazione del mio eBook gratuito " Use The Index, Luke ". Passo molto del mio tempo a spiegare come funzionano gli indici e come usarli correttamente.

Voglio solo sottolineare un'osservazione: sembra che la maggior parte delle risposte presuma che il database sia intercambiabile con i database relazionali. Esistono anche database di oggetti, database di file flat. È importante valutare le esigenze del progetto software in questione. Dal punto di vista del programmatore, la decisione sul database può essere rimandata a più tardi. La modellazione dei dati, d'altra parte, può essere raggiunta presto e portare a un grande successo.

Penso che la modellazione dei dati sia un componente chiave ed è un concetto relativamente vecchio ma è stato dimenticato da molti nel settore del software. La modellazione dei dati, in particolare la modellazione concettuale, può rivelare il comportamento funzionale di un sistema e può essere considerata una road map per lo sviluppo.

D'altra parte, il tipo di database richiesto può essere determinato in base a molti fattori diversi per includere l'ambiente, il volume utente e l'hardware locale disponibile come lo spazio sul disco rigido.

Evitare l' iniezione SQL e come proteggere il database

Ogni sviluppatore dovrebbe sapere che questo è falso: "La profilazione di un'operazione di database è completamente diversa dalla profilatura del codice."

C'è un chiaro Big-O nel senso tradizionale. Quando fai un EXPLAIN PLAN(o l'equivalente) vedi l'algoritmo. Alcuni algoritmi coinvolgono cicli annidati e sono O ( n ^ 2). Altri algoritmi coinvolgono ricerche B-tree e sono O ( n log n ).

Questo è molto, molto serio. È fondamentale per capire perché gli indici sono importanti. È fondamentale per comprendere i compromessi tra velocità di normalizzazione e denormalizzazione. È fondamentale capire perché un data warehouse utilizza uno schema a stella che non è normalizzato per gli aggiornamenti transazionali.

Se non sei chiaro sull'algoritmo utilizzato, procedi come segue. Fermare. Spiegare il piano di esecuzione della query. Regola gli indici di conseguenza.

Inoltre, il corollario: più indici non sono migliori.

A volte un indice focalizzato su un'operazione rallenta altre operazioni. A seconda del rapporto tra le due operazioni, l'aggiunta di un indice può avere buoni effetti, nessun impatto complessivo o essere dannoso per la performance complessiva.

Penso che ogni sviluppatore dovrebbe capire che i database richiedono un paradigma diverso .

Quando si scrive una query per ottenere i dati, è necessario un approccio basato su set. Molte persone con un background interativo lottano con questo. Eppure, quando lo accettano, possono ottenere risultati di gran lunga migliori, anche se la soluzione potrebbe non essere quella che per prima si è presentata nelle loro menti focalizzate sull'iterazione.

Ottima domanda. Vediamo, prima nessuno dovrebbe prendere in considerazione la possibilità di interrogare un database che non comprende a fondo i join. È come guidare un'auto senza sapere dove sono il volante e i freni. Devi anche conoscere i tipi di dati e come scegliere il migliore.

Un'altra cosa che gli sviluppatori dovrebbero capire è che ci sono tre cose da tenere a mente quando si progetta un database:

1. Integrità dei dati: se non è possibile fare affidamento sui dati, essenzialmente non si dispone di dati, questo significa non inserire la logica richiesta nell'applicazione poiché molte altre fonti potrebbero toccare il database. Vincoli, chiavi esterne e talvolta trigger sono necessari per l'integrità dei dati. Non mancare di usarli perché non ti piacciono o non vuoi essere disturbato a capirli.

2. Prestazioni: è molto difficile eseguire il refactoring di un database con prestazioni scadenti e le prestazioni dovrebbero essere considerate dall'inizio. Esistono molti modi per eseguire la stessa query e alcuni sono noti per essere più veloci quasi sempre, è miope non imparare e utilizzare questi modi. Leggere alcuni libri sull'ottimizzazione delle prestazioni prima di progettare query o strutture di database.

3. Sicurezza: questi dati sono la linfa vitale della tua azienda, spesso contengono anche informazioni personali che possono essere rubate. Impara a proteggere i tuoi dati da attacchi SQL injection, frodi e furti di identità.

Quando si interroga un database, è facile ottenere la risposta sbagliata. Assicurati di comprendere a fondo il tuo modello di dati. Ricorda che spesso le decisioni effettive vengono prese in base ai dati restituiti dalla query. Quando è sbagliato, vengono prese le decisioni aziendali sbagliate. Puoi uccidere un'azienda da domande sbagliate o perdere un grande cliente. I dati hanno un significato, gli sviluppatori spesso sembrano dimenticarlo.

I dati non scompaiono quasi mai, pensa in termini di archiviazione dei dati nel tempo invece che come ottenerli oggi. Quel database che funzionava bene quando aveva centomila record, potrebbe non essere così bello tra dieci anni. Le applicazioni raramente durano quanto i dati. Questo è uno dei motivi per cui la progettazione per le prestazioni è fondamentale.

Il tuo database probabilmente avrà bisogno di campi che l'applicazione non ha bisogno di vedere. Cose come GUID per la replica, campi di data inserita. ecc. Potrebbe anche essere necessario memorizzare la cronologia delle modifiche e chi le ha apportate quando ed essere in grado di ripristinare le modifiche errate da questo magazzino. Pensa a come intendi farlo prima di chiedere a un sito web come risolvere il problema in cui ti sei dimenticato di mettere una clausola where su un aggiornamento e hai aggiornato l'intera tabella.

Non sviluppare mai in una versione più recente di un database rispetto alla versione di produzione. Mai, mai, mai sviluppare direttamente su un database di produzione.

Se non si dispone di un amministratore di database, assicurarsi che qualcuno stia eseguendo backup e sappia come ripristinarli e che abbia testato il ripristino.

Il codice del database è codice, non ci sono scuse per non tenerlo nel controllo del codice sorgente proprio come il resto del codice.

Progettazione di database evolutivi. http://martinfowler.com/articles/evodb.html

Queste metodologie agili rendono il processo di modifica del database gestibile, prevedibile e testabile.

Gli sviluppatori dovrebbero sapere cosa serve per effettuare il refactoring di un database di produzione in termini di controllo della versione, integrazione continua e test automatizzati.

Il processo di progettazione evolutiva del database ha aspetti amministrativi, ad esempio una colonna deve essere eliminata dopo un certo periodo di vita in tutti i database di questa base di codice.

Sappi almeno che esistono il concetto e le metodologie di refactoring del database. http://www.agiledata.org/essays/databaseRefactoringCatalog.html

La classificazione e la descrizione del processo rendono possibile implementare strumenti anche per questi refactoring.

Dalla mia esperienza con i database relazionali, ogni sviluppatore dovrebbe sapere:

- I diversi tipi di dati :

L'utilizzo del tipo corretto per il lavoro corretto renderà la progettazione del database più robusta, le query più veloci e la vita più facile.

- Informazioni su 1xM e MxM :

Questo è il pane quotidiano per i database relazionali. È necessario comprendere le relazioni uno-a-molti e molti-a-molti e applicarle quando appropriato.

- Il principio " KISS " si applica anche al DB :

La semplicità funziona sempre meglio. A condizione che tu abbia studiato come funziona il DB, eviterai complessità inutili che porteranno a problemi di manutenzione e velocità.

- Indici :

Non è abbastanza se sai cosa sono. Devi capire quando usarli e quando no.

anche:

• L'algebra booleana è tua amica
• Immagini: non memorizzarle nel DB. Non chiedere perché.
• Prova CANCELLA con SELEZIONA

Vorrei che tutti, sia gli amministratori di database che gli sviluppatori / designer / architetti, comprendessero meglio come modellare correttamente un dominio aziendale e come mappare / tradurre quel modello di dominio aziendale in un modello logico di database normalizzato, un modello fisico ottimizzato e un un modello di classe orientato agli oggetti appropriato, ognuno dei quali è (può essere) diverso, per vari motivi, e capisce quando, perché e come sono (o dovrebbero essere) diversi l'uno dall'altro.

Direi forti abilità SQL di base. Finora ho visto molti sviluppatori che conoscono un po 'i database ma chiedono sempre suggerimenti su come formulare una query abbastanza semplice. Le domande non sono sempre così facili e semplici. È necessario utilizzare più join (interno, sinistro, ecc.) Quando si interroga un database ben normalizzato.

Circa il seguente commento alla risposta di Walter M.:

"Scritto molto bene! E la prospettiva storica è ottima per le persone che non lavoravano sui database in quel momento (cioè io)".

La prospettiva storica è in un certo senso assolutamente cruciale. "Chi dimentica la storia, è condannato a ripeterla". Cfr XML che ripete gli errori gerarchici del passato, database grafici che ripetono gli errori di rete del passato, sistemi OO che impongono il modello gerarchico agli utenti mentre tutti con anche solo un decimo di cervello dovrebbero sapere che il modello gerarchico non è adatto per il generale- rappresentazione dello scopo del mondo reale, eccetera, eccetera.

Per quanto riguarda la domanda stessa:

Ogni sviluppatore di database dovrebbe sapere che "Relazionale" non è uguale a "SQL". Allora capirebbero perché vengono delusi in modo così abissale dai fornitori di DBMS, e perché dovrebbero dire a quegli stessi fornitori di inventare cose migliori (ad esempio DBMS che sono veramente relazionali) se vogliono continuare a succhiare quantità esilaranti di soldi dai loro clienti per un software così scadente).

E ogni sviluppatore di database dovrebbe sapere tutto sull'algebra relazionale. Allora non ci sarebbe più stato un solo sviluppatore a dover postare queste stupide domande "Non so come fare il mio lavoro e voglio che qualcun altro lo faccia per me" su Stack Overflow.

Penso che molti dettagli tecnici siano stati trattati qui e non voglio aggiungerli. L'unica cosa che voglio dire è più sociale che tecnica, non cadere nella trappola "DBA conosce il meglio" come sviluppatore di applicazioni.

Se riscontri problemi di prestazioni con la query, prendi la responsabilità anche del problema. Fai le tue ricerche e spingi i DBA per spiegare cosa sta succedendo e come le loro soluzioni stanno affrontando il problema.

Fornisci anche i tuoi suggerimenti dopo aver fatto la ricerca. Cioè, cerco di trovare una soluzione cooperativa al problema piuttosto che lasciare i problemi del database agli amministratori di database.

Semplice rispetto.

• Non è solo un repository
• Probabilmente non conosci meglio del venditore o degli amministratori di database
• Non lo sosterrai alle 3 del mattino con i senior manager che ti urlano contro

Considera la denormalizzazione come un possibile angelo, non il diavolo, e considera anche i database NoSQL come un'alternativa ai database relazionali.

Inoltre, penso che il modello Entity-Relation sia un must per ogni sviluppatore anche se non si progettano database. Ti permetterà di capire a fondo di cosa tratta il tuo database.

Non inserire mai dati con la codifica del testo sbagliata.

Una volta che il tuo database è stato contaminato da più codifiche, il meglio che puoi fare è applicare una sorta di combinazione di euristica e lavoro manuale.

A parte la sintassi e le opzioni concettuali che impiegano (come join, trigger e stored procedure), una cosa che sarà fondamentale per ogni sviluppatore che impiega un database è questa:

Scopri come il tuo motore eseguirà la query che stai scrivendo con specificità.

Il motivo per cui penso che sia così importante è semplicemente la stabilità della produzione. Dovresti sapere come si comporta il tuo codice in modo da non interrompere tutta l'esecuzione nel thread mentre aspetti il ​​completamento di una lunga funzione, quindi perché non dovresti sapere come la tua query influenzerà il database, il tuo programma e forse anche il server?

Questo è in realtà qualcosa che ha colpito il mio team di ricerca e sviluppo più volte rispetto a punti e virgola mancanti o simili. La presunzione è che la query verrà eseguita rapidamente perché lo fa sul loro sistema di sviluppo con solo poche migliaia di righe nelle tabelle. Anche se il database di produzione ha le stesse dimensioni, è più che probabile che verrà utilizzato molto di più e quindi soffrirà di altri vincoli come più utenti che accedono allo stesso tempo o qualcosa che non va con un'altra query altrove, ritardando così il risultato di questa query.

Anche cose semplici come il modo in cui i join influenzano le prestazioni di una query sono inestimabili nella produzione. Ci sono molte caratteristiche di molti motori di database che semplificano le cose concettualmente, ma possono introdurre trucchi nelle prestazioni se non pensate chiaramente.

Conosci il tuo processo di esecuzione del motore di database e pianificalo.

Per uno sviluppatore professionista di medio livello che utilizza molto database (scrivendo / gestendo query quotidianamente o quasi quotidianamente), penso che l'aspettativa dovrebbe essere la stessa di qualsiasi altro campo: ne hai scritto uno al college .

Ogni appassionato di C ++ ha scritto una lezione di stringhe al college. Ogni appassionato di grafica ha scritto un raytracer al college. Ogni fanatico del web ha scritto siti web interattivi (di solito prima che avessimo "framework web") al college. Tutti i nerd dell'hardware (e anche i nerd del software) hanno costruito una CPU al college. Ogni medico ha dissezionato un intero cadavere al college, anche se mi misurerà la pressione sanguigna e mi dirà che il mio colesterolo è troppo alto oggi. Perché i database dovrebbero essere diversi?

Purtroppo, oggi, per qualche motivo, sembrano diversi. Le persone vogliono che i programmatori .NET sappiano come funzionano le stringhe in C , ma le parti interne del tuo RDBMS non dovrebbero preoccuparti troppo .

È praticamente impossibile ottenere lo stesso livello di comprensione solo leggendo su di loro, o anche scendendo dall'alto. Ma se inizi dal basso e comprendi ogni pezzo, allora è relativamente facile capire le specifiche per il tuo database. Persino cose che molti fanatici del database non riescono a cogliere, come quando usare un database non relazionale.

Forse è un po 'severo, soprattutto se non hai studiato informatica al college. Ne ridurrò un po ': potresti scriverne uno oggi , completamente, da zero. Non mi interessa se conosci le specifiche di come funziona l'ottimizzatore di query PostgreSQL, ma se ne sai abbastanza per scriverne uno tu stesso, probabilmente non sarà troppo diverso da quello che hanno fatto. E sai, non è davvero così difficile scriverne uno di base.

L'ordine delle colonne in un indice non univoco è importante.

La prima colonna dovrebbe essere la colonna che ha la maggiore variabilità nel suo contenuto (cioè cardinalità).

Ciò aiuta la capacità di SQL Server di creare statistiche utili su come utilizzare l'indice in fase di esecuzione.

Comprendi gli strumenti che utilizzi per programmare il database !!!

Ho perso così tanto tempo cercando di capire perché il mio codice stava misteriosamente fallendo.

Se utilizzi .NET, ad esempio, devi sapere come utilizzare correttamente gli oggetti nello System.Data.SqlClientspazio dei nomi. Devi sapere come gestire il tuoSqlConnection oggetti per assicurarti che siano aperti, chiusi e, quando necessario, smaltiti correttamente.

Devi sapere che quando usi a SqlDataReader, è necessario chiuderlo separatamente dal tuo SqlConnection. È necessario capire come mantenere aperte le connessioni quando appropriato per ridurre al minimo il numero di accessi al database (perché sono relativamente costosi in termini di tempo di elaborazione).

• Competenze SQL di base.
• Indicizzazione.
• Gestisci diverse incarnazioni di DATE / TIME / TIMESTAMP.
• Documentazione del driver JDBC per la piattaforma in uso.
• Gestire i tipi di dati binari ( CLOB , BLOB , ecc.)

Per alcuni progetti, e il modello orientato agli oggetti è migliore.

Per altri progetti, un modello relazionale è migliore.

Il problema del disadattamento di impedenza e conoscere le carenze comuni o ORM.

Compatibilità RDBMS

Controlla se è necessario per eseguire l'applicazione in più di un RDBMS. In caso affermativo, potrebbe essere necessario:

• evitare le estensioni RDBMS SQL
• eliminare i trigger e memorizzare le procedure
• seguire rigorosi standard SQL
• convertire i tipi di dati dei campi
• modificare i livelli di isolamento delle transazioni

Altrimenti, queste domande dovrebbero essere trattate separatamente e verrebbero sviluppate diverse versioni (o configurazioni) dell'applicazione.

Non dipendere dall'ordine delle righe restituite da una query SQL.

http://www.reddit.com/r/programming/comments/azdd7/programmers_sit_your_butt_down_i_need_to_have_a/