Spesso (troppo spesso ahimè), per lavoro, sono costretto a dover “mettere mano” a database progettati (si fà per dire 😛 ) da altri prima di me. La cosa diventa assolutamente irritante quando ti rendi conto che, i database in questione, sono stati progettati (si fà sempre per dire 😛 ) da persone che probabilmente non sanno manco cosa significhi la parola database…probabilmente avranno utilizzato Wikipedia per capirne il significato solo dopo che lo sfortunato “successore” avrà chiesto loro: “ma sto database l’hai progettato mentre facevi lotta greco-romana con un Mammut?”.
E’ davvero incredibile come ci si possa imbattere in errori a dir poco grossolani:
– Assenza di chiave primaria in una tabella
– Ridondanza dei dati
– Utilizzo di tabelle superflue (tanto che ci frega, più ce ne sono più siamo fighi…bah 😀 )
– Nomi dei campi scelti con grande cura (avresti mai pensato che un campo ID_FAQ serve a memorizzare il codice embed di un video YouTube? 😀 )
In tanti anni di lavoro ne ho viste tantissime…potrei scrivere un libro. Magari faccio qualche soldino e mi compro Facebook con l’unico obiettivo di diventare il capo di Zuckerberg e togliermi lo sfizio di obbligarlo a mettere le scarpe 😀
Un consiglio che voglio dare ai giovani developers sulla progettazione di un database è, ovviamente, quello di studiare a fondo l’argomento. Analisi e progettazione devono essere semplicemente perfette, nulla deve essere lasciato al caso. Una cosa importante che consiglio è di leggere e comprendere la normalizzazione e il modello relazionale (non limitarti alle informazioni di Wikipedia, approfondisci l’argomento).
Poi, in rete, materiale se ne trova, libri ce ne sono e puoi anche dare un’occhiata a due miei vecchi post…del 2008 ma ancora validi 😀
– Progettare database in modo professionale (Parte 1)
– Progettare database in modo professionale (Parte 2)
Ora confessa nei commenti se il tuo modo di progettare database è altamente professionale o altamente imbarazzante 😉
[…] This post was mentioned on Twitter by Claudia ♀ | ./lsd, Emanuele Calì. Emanuele Calì said: L’importanza di una perfetta analisi e progettazione di un database http://goo.gl/3WWhV […]
Quanto darti ragione!!!!!!
L’errore più comune (non di progettazione però) che ho trovato in giro era memorizzare le password in chiaro sul database! ora magari non dico che ci vuole sempre una codifica a 256bit ma almeno una base64 giusto per far perdere quei 2 secondi in piu. 🙂
Comunque hai ragione in pieno quando dici che non basterebbe un libro! Basti pensare alla gara che fanno alcuni “ingegneri” (consentimi lo sfottò)
…quando giocano a: “chi crea piu tabelle vince”. 🙂
Ps. scusa il doppio post ma ho inviato per sbaglio. Se completi il primo questo cancellalo tranquillamente. Sorry
@Simone è troppo vero, le password in chiaro le trovi fin troppo spesso, allucinante! 😀