Cattive pratiche nella progettazione di database: stai commettendo questi errori?

Ogni volta che a te, come sviluppatore, viene assegnata un'attività basata sul codice esistente, devi affrontare molte sfide. Una di queste sfide, il più delle volte la più impegnativa, riguarda la comprensione del modello di dati di un'applicazione.

Ci si trova normalmente di fronte a tabelle, viste, colonne, valori, procedure archiviate, funzioni, vincoli e trigger confusi che richiedono molto tempo per avere un senso. E, una volta fatto, inizi a notare molti modi per migliorare e sfruttare le informazioni memorizzate.

Se sei uno sviluppatore esperto, è probabile che noterai anche cose che avrebbero potuto essere fatte meglio all'inizio, ad esempio, difetti di progettazione.

In questo articolo, imparerai alcune delle pratiche scorrette di progettazione di database comuni, perché sono cattive e come evitarle.

Cattiva pratica n. 1: ignorare lo scopo dei dati

I dati vengono archiviati per essere consumati in seguito e l'obiettivo è sempre archiviarli e recuperarli nel modo più efficiente. Per raggiungere questo obiettivo, il progettista del database deve sapere in anticipo cosa rappresenteranno i dati, come verranno acquisiti e con quale velocità, quale sarà il suo volume operativo (cioè, quanti dati sono previsti) e, infine , come verrà utilizzato.

Ad esempio, un sistema informativo industriale in cui i dati vengono raccolti manualmente ogni giorno non avrà lo stesso modello di dati di un sistema industriale in cui le informazioni vengono generate in tempo reale. Come mai? Perché è molto diverso gestire alcune centinaia o migliaia di record al mese rispetto a gestirne milioni nello stesso periodo. Considerazioni speciali devono essere fatte dai progettisti al fine di mantenere l'efficienza e l'usabilità del database, se i volumi di dati devono essere grandi.

Ma, ovviamente, il volume dei dati non è l'unico aspetto da considerare, poiché lo scopo dei dati influisce anche sul livello di normalizzazione, sulla struttura dei dati, sulla dimensione del record e sull'implementazione generale dell'intero sistema.

Pertanto, la conoscenza approfondita dello scopo del sistema di dati che si creerà porta a considerazioni nella scelta del motore di database, delle entità da progettare, delle dimensioni e del formato del record e delle politiche di gestione del motore di database.

Ignorare questi obiettivi porterà a progetti che presentano difetti di base, sebbene strutturalmente e matematicamente corretti.

Cattiva pratica n. 2: scarsa normalizzazione

La progettazione di un database non è un compito deterministico; due progettisti di database possono seguire tutte le regole ei principi di normalizzazione per un determinato problema e nella maggior parte dei casi genereranno layout di dati diversi. Questo è inerente alla natura creativa dell'ingegneria del software. Tuttavia, ci sono alcune tecniche di analisi che hanno un senso in ogni caso, e seguirle è il modo migliore per arrivare a un database che funziona al meglio.

Nonostante ciò, ci troviamo spesso di fronte a database progettati al volo senza seguire le più elementari regole di normalizzazione. Dobbiamo essere chiari su questo: ogni database dovrebbe, almeno, essere normalizzato alla terza forma normale, poiché è il layout che rappresenterà al meglio le tue entità e le cui prestazioni saranno meglio bilanciate tra query e inserimento-aggiornamento-eliminazione di record .

Se ti imbatti in tabelle che non sono conformi a 3NF, 2NF o anche 1NF, considera la possibilità di riprogettare queste tabelle. Lo sforzo che investi in questo modo ripagherà a brevissimo termine.

Cattiva pratica n. 3: ridondanza

Molto correlato al punto precedente, poiché uno degli obiettivi della normalizzazione è ridurlo, la ridondanza è un'altra cattiva pratica che appare abbastanza spesso.

I campi e le tabelle ridondanti sono un incubo per gli sviluppatori, poiché richiedono la logica aziendale per mantenere aggiornate molte versioni delle stesse informazioni. Si tratta di un sovraccarico che può essere evitato se si seguono scrupolosamente le regole di normalizzazione. Sebbene a volte la ridondanza possa sembrare necessaria, deve essere utilizzata solo in casi molto specifici ed essere chiaramente documentata per essere presa in considerazione negli sviluppi futuri.

I tipici effetti negativi della ridondanza sono un aumento non necessario delle dimensioni del database, dati inclini all'incoerenza e diminuzione dell'efficienza del database, ma, cosa ancora più importante, può causare il danneggiamento dei dati.

Cattiva pratica n. 4: Cattiva integrità referenziale (vincoli)

L'integrità referenziale è uno degli strumenti più preziosi forniti dai motori di database per mantenere la migliore qualità dei dati. Se sin dalla fase di progettazione non vengono implementati vincoli o vengono implementati pochissimi vincoli, l'integrità dei dati dovrà basarsi interamente sulla logica aziendale, rendendoli suscettibili all'errore umano.

Cattiva pratica n. 5: non sfruttare le funzionalità del motore DB

Quando si utilizza un motore di database (DBE), si dispone di un potente software per le attività di gestione dei dati che semplificherà lo sviluppo del software e garantirà che le informazioni siano sempre corrette, sicure e utilizzabili. Un DBE fornisce servizi come:

• Visualizzazioni che forniscono un modo rapido ed efficiente per esaminare i dati, in genere denormalizzandoli a scopo di query senza perdere la correttezza dei dati.
• Indici che aiutano a velocizzare le query sulle tabelle.
• Funzioni aggregate che aiutano ad analizzare le informazioni senza programmazione.
• Transazioni o blocchi di frasi che alterano i dati che vengono tutte eseguite e commesse o annullate (rollback) se si verifica qualcosa di imprevisto, mantenendo così le informazioni in uno stato perennemente corretto.
• Blocchi che mantengono i dati al sicuro e corretti durante l'esecuzione delle transazioni.
• Stored procedure che forniscono funzionalità di programmazione per consentire complesse attività di gestione dei dati.
• Funzioni che consentono calcoli sofisticati e trasformazioni di dati.
• Vincoli che aiutano a garantire la correttezza dei dati ed evitare errori.
• Trigger che aiutano ad automatizzare le azioni quando si verificano eventi sui dati.
• Ottimizzatore di comandi (pianificatore di esecuzione) che gira sotto il cofano, assicurando che ogni frase venga eseguita al meglio e mantenendo i piani di esecuzione per le occasioni future. Questo è uno dei migliori motivi per utilizzare viste, stored procedure e funzioni, poiché i loro piani di esecuzione vengono mantenuti permanentemente nel DBE.

Non conoscere o ignorare queste capacità porterà lo sviluppo su un percorso estremamente incerto e sicuramente verso bug e problemi futuri.

Cattiva pratica n. 6: chiavi primarie composite

Questo è un punto controverso, dal momento che molti progettisti di database parlano oggigiorno di utilizzare un campo generato automaticamente da un ID intero come chiave primaria invece di uno composto definito dalla combinazione di due o più campi. Questa è attualmente definita come la “best practice” e, personalmente, tendo ad essere d'accordo con essa.

Tuttavia, questa è solo una convenzione e, naturalmente, i DBE consentono la definizione di chiavi primarie composite, che molti designer ritengono inevitabili. Pertanto, come per la ridondanza, le chiavi primarie composite sono una decisione di progettazione.

Attenzione, tuttavia, se la tabella con una chiave primaria composita dovrebbe avere milioni di righe, l'indice che controlla la chiave composita può crescere fino a un punto in cui le prestazioni dell'operazione CRUD sono molto ridotte. In tal caso, è molto meglio utilizzare una semplice chiave primaria ID intero il cui indice sarà sufficientemente compatto e stabilirà i vincoli DBE necessari per mantenere l'unicità.

Cattiva pratica n. 7: scarsa indicizzazione

A volte, avrai una tabella che devi interrogare per molte colonne. Man mano che la tabella cresce, noterai che i SELECT su queste colonne rallentano. Se la tabella è abbastanza grande, penserai, logicamente, di creare un indice su ogni colonna che usi per accedere a questa tabella solo per scoprire quasi immediatamente che le prestazioni di SELECT migliorano ma INSERT, UPDATE e DELETE diminuiscono. Ciò, ovviamente, è dovuto al fatto che gli indici devono essere mantenuti sincronizzati con la tabella, il che significa un enorme sovraccarico per il DBE. Questo è un tipico caso di sovraindicizzazione che puoi risolvere in molti modi; ad esempio, avere un solo indice su tutte le colonne diverso dalla chiave primaria utilizzata per interrogare la tabella, ordinare queste colonne dalla più utilizzata alla meno può offrire prestazioni migliori in tutte le operazioni CRUD rispetto a un indice per colonna.

D'altra parte, avere una tabella senza indice sulle colonne utilizzate per interrogarla, come tutti sappiamo, porterà a scarse prestazioni su SELECT.

Inoltre, l'efficienza dell'indice dipende talvolta dal tipo di colonna; gli indici sulle colonne INT mostrano le migliori prestazioni possibili, ma gli indici su VARCHAR, DATE o DECIMAL (se ha senso) non sono così efficienti. Questa considerazione può anche portare a riprogettare le tabelle a cui è necessario accedere con la migliore efficienza possibile.

Pertanto, l'indicizzazione è sempre una decisione delicata, poiché troppa indicizzazione può essere tanto negativa quanto troppo piccola e perché il tipo di dati delle colonne su cui indicizzare ha una grande influenza sul risultato finale.

Cattiva pratica n. 8: Convenzioni di denominazione scadenti

Questo è qualcosa con cui i programmatori hanno sempre difficoltà di fronte a un database esistente: capire quali informazioni sono memorizzate in esso tramite i nomi di tabelle e colonne perché, spesso, non c'è altro modo.

Il nome della tabella deve descrivere quale entità contiene e ogni nome di colonna deve descrivere quale informazione rappresenta. Questo è facile, ma inizia a essere complicato quando le tabelle devono relazionarsi tra loro. I nomi iniziano a diventare disordinati e, peggio, se ci sono convenzioni di denominazione confuse con norme illogiche (come, ad esempio, "il nome della colonna deve essere di 8 caratteri o meno"). La conseguenza finale è che il database diventa illeggibile.

Pertanto, una convenzione di denominazione è sempre necessaria se si prevede che il database duri e si evolva con l'applicazione che supporta, ed ecco alcune linee guida per stabilirne una concisa, semplice e leggibile:

• Nessuna limitazione alla dimensione del nome della tabella o della colonna. È meglio avere un nome descrittivo che un acronimo che nessuno ricorda o capisce.
• Nomi uguali hanno lo stesso significato. Evita di avere campi che hanno lo stesso nome ma con tipi o significati diversi; questo prima o poi sarà fonte di confusione.
• A meno che non sia necessario, non essere ridondante. Ad esempio, nella tabella "Articolo", non è necessario avere colonne come "Nomeoggetto", "PrezzoOf" o nomi simili; Bastano “Nome” e “Prezzo”.
• Attenzione alle parole riservate DBE. Se una colonna deve essere chiamata "Indice", che è una parola riservata SQL, prova a usarne una diversa come "NumeroIndice".
• Se ti attieni alla semplice regola della chiave primaria (un intero intero generato automaticamente), chiamalo "Id" in ogni tabella.
• Se ci si unisce ad un'altra tabella, definire la chiave esterna necessaria come un intero, denominato “Id” seguito dal nome della tabella unita (es. IdItem).
• Se si denomina i vincoli, utilizzare un prefisso che descrive il vincolo (ad esempio, "PK" o "FK"), seguito dal nome della tabella o delle tabelle interessate. Ovviamente, l'utilizzo di trattini bassi ("_") aiuta a rendere le cose più leggibili.
• Per denominare gli indici, utilizzare il prefisso “IDX” seguito dal nome della tabella e dalla colonna o dalle colonne dell'indice. Inoltre, usa "UNIQUE" come prefisso o suffisso se l'indice è univoco e sottolinea se necessario.

Esistono molte linee guida per la denominazione dei database su Internet che faranno luce su questo aspetto molto importante della progettazione del database, ma con queste linee guida di base puoi almeno ottenere un database leggibile. Ciò che è importante qui non è la dimensione o la complessità delle tue linee guida per la denominazione, ma la tua coerenza nel seguirle!

Alcune osservazioni finali

La progettazione di database è una combinazione di conoscenza ed esperienza; l'industria del software si è evoluta molto dai suoi primi giorni. Fortunatamente, sono disponibili conoscenze sufficienti per aiutare i progettisti di database a ottenere i migliori risultati.

Esistono buone linee guida per la progettazione di database su Internet, nonché cattive pratiche e cose da evitare nella progettazione di database. Basta prendere la tua scelta e attenersi ad essa.

E, non dimenticare, è solo attraverso la sperimentazione, gli errori e i successi che impari, quindi vai avanti e inizia ora.