Normalizzare Database già in produzione

ccuomo

il 25 set 2018, 09:09

39 risposte

ccuomo

Pochi posts

Iscritto da: apr, 2010

Messaggi:: 33

Normalizzare Database già in produzione

25 set 2018, 09:28

Un saluto a tutti,
circa 5 anni fa progettai una web application che naturalmente utilizza come motore db mysql

La web application funziona perfettamente, il problema è che nel database mi ritrovo migliaia di dati duplicati, per darvi un'idea trattandosi di una web application orientata a officina meccanica, mi ritrovo la stessa targa ripetuta per ogni singolo intervento che negli anni abbiamo fatto ad un cliente.

La mia domanda è: a distanza di anni e avendo il database popolato è ancora possibile (naturalmente sistemando le varie query lato php) effettuare una normalizzazione che mi permette di eliminare dalle tabelle tutti i valori duplicati ?

Sono consapevole che la domanda è alquanto bizzarra ma non saprei quale altra soluzione adottare.

Grazie

39 Risposte

+
+m2+
Utente Famoso
Iscritto da
mag, 2017
Messaggi:
3548
Re: Normalizzare Database già in produzione
25 set 2018, 09:38
La domanda è banale, e la risposta altrettanto (cioè sì).
ma poi ci sono i due assiomi fondamentali della informatica che compendio così : perché lo vuoi fare?
O
OsvaldoLaviosa
Super Famoso
Iscritto da
apr, 2012
Messaggi:
7493
Re: Normalizzare Database già in produzione
25 set 2018, 10:35
Io non so usare MySQL, ma la NORMALIZZAZIONE è doverosa. In Access esiste un tool che aiuta l'utente a correggere questo "errore". Non saprei se esiste pure in MySQL, altrimenti devi tutto modificare manualmente.
+
+m2+
Utente Famoso
Iscritto da
mag, 2017
Messaggi:
3548
Re: Normalizzare Database già in produzione
25 set 2018, 10:39
OsvaldoLaviosa ha scritto:
Io non so usare MySQL, ma la NORMALIZZAZIONE è doverosa
perché, altrimenti, che succede?
Scoppia la guerra Israele Iran?
Trump si tinge i capelli?
non credo.
va prima capito perché normalizzare, prima di decidere se farlo.
altrimenti si procede come i dilettanti: non so perché sto facendo qualcosa
M
migliorabile
Super Famoso
Iscritto da
apr, 2013
Messaggi:
6045
Re: Normalizzare Database già in produzione
25 set 2018, 10:54
In generale la normalizzazione di un database va fatta in fase di progettazione e cercando, nello stesso momento, di non incasinare eccessivamente le query: un po' di doppioni di informazioni ci possono anche stare se semplificano notevolmente la query (invede di avere n-mila join).

I vari tipi di normalizzazione sono stati pensati per ovviare a specifici tipi di problemi, ma introduce anche rogne di vario genere.

Ad esempio: se ho un utente che ha acquistato qualcosa per la sua automobile 5 anni fa, e la targa era XX111XX, ed oggi ha cambiato automobile e la targa e' YY999YY, se le cose non sono fatte con le dovute attenzioni, rischi di ritrovarti la fattura di 5 anni fa con riferimento alla targa YY999YY !

Quindi, normalizzazione si, ma con cognizione di causa.

QUINDI, per prima cosa ti DEVI STUDIARE che cosa e' il modello relazionale dei dati, POI quali sono le diverse tipologie di normalizzazione, QUINDI metterti a tavolino e vedere dove

1) e' NECESSARIO normalizzare, perche' altrimenti gli aggiornamenti sono un bagno di sangue
2) sarebbe utile, ma non indispensabile
3) e' rischiso/deleterio
C
ccuomo
Pochi posts
Iscritto da
apr, 2010
Messaggi:
33
Re: Normalizzare Database già in produzione
25 set 2018, 12:13
Le vostre sono delle considerazioni più che sensate e vi confesso che il mio desiderio di normalizzare i dati nasce da una (a mio avviso) reale necessità. Il mio gestionale si occupa sostanzialmente di gestire appuntamenti e registrare commesse di lavoro. Ora il problema nasce nel momento in cui eseguo a titolo di esempio 30 lavori su di un veicolo targato FF123AA, nel database mi ritrovo 30 righe con la stessa targa ma con interventi diversi, ed è quello che succede oggi, dove nella tabella commesse ho circa 5200 record di cui 2110 sono le targhe che vengono fuori se eseguo
```
SELECT DISTINCT targa FROM comm ORDER BY targa ASC;
```
O
OsvaldoLaviosa
Super Famoso
Iscritto da
apr, 2012
Messaggi:
7493
Re: Normalizzare Database già in produzione
25 set 2018, 12:59
Potresti elencare tutti i nomi campi della tua tabella?
+
+m2+
Utente Famoso
Iscritto da
mag, 2017
Messaggi:
3548
Re: Normalizzare Database già in produzione
25 set 2018, 13:00
... E... Quindi?... Cosa ti turba?
Il programma fa quello che è previsto?
C
ccuomo
Pochi posts
Iscritto da
apr, 2010
Messaggi:
33
Re: Normalizzare Database già in produzione
25 set 2018, 15:04
+m2+ ha scritto:
... E... Quindi?... Cosa ti turba?
Il programma fa quello che è previsto?
Certo,
il programma fa esattamente quello che deve fare, mi turba che a lungo andare la dimensione della tabella espressa in Mb può raggiungere notevoli dimensioni. Allo stato attuale è pari e circa 2.5 Mb

Solo questo mi preoccupa
+
+m2+
Utente Famoso
Iscritto da
mag, 2017
Messaggi:
3548
Re: Normalizzare Database già in produzione
25 set 2018, 15:09
ccuomo ha scritto:
+m2+ ha scritto:
... E... Quindi?... Cosa ti turba?
Il programma fa quello che è previsto?
Certo,
il programma fa esattamente quello che deve fare,
Dovresti fermarti qui
mi turba che a lungo andare la dimensione della tabella espressa in Mb può raggiungere notevoli dimensioni. Allo stato attuale è pari e circa 2.5 Mb

Solo questo mi preoccupa
Se in 5 anni è diventato 2.5MB, quando diventerà, secondo la tua stima, di dimensioni notevoli?
Tra 5000 anni sarà 2.5GB, cioè elaborabile da un cellulare.
Forse tra 50.000 anni dovrai iniziare a preoccuparti
---
Non lo dico in termini spregiativi, ma proprio per insegnarti a valutare e misurare cosa fai, e perchè lo fai.
Un database è grande quando il SUO INDICE è PIU' GRANDE della memoria disponibile (RAM).
(...cuttone su spiegone titanico...) con le macchine odierne, da computer discount, così spannometricamente, fino a un 20GB puoi stare tranquillissimo.
Che è un fattore circa 8.000 volte il tuo DB.
Quando avrai questo problema, significa che avrete una multinazionale così grande, da miliardi di dollari, da poterne pagare qualcuno a un tizio come me (cioè in grado di gestire una tabella da decine di miliardi di righe).

Fino a quel momento...perchè cambiare qualcosa che funziona?

ccuomo

Pochi posts

Iscritto da: apr, 2010

Messaggi:: 33

Re: Normalizzare Database già in produzione

25 set 2018, 15:10

OsvaldoLaviosa ha scritto:
Potresti elencare tutti i nomi campi della tua tabella?


CREATE TABLE `commesse` (
  `id_com` int(11) NOT NULL,
  `veicolo` varchar(30) DEFAULT NULL,
  `targa` varchar(10) DEFAULT NULL,
  `km` varchar(50) DEFAULT NULL,
  `telaio` varchar(30) DEFAULT NULL,
  `cliente` varchar(50) DEFAULT NULL,
  `indirizzo` varchar(50) DEFAULT NULL,
  `piva` varchar(12) DEFAULT NULL,
  `tel` varchar(30) DEFAULT NULL,
  `itr1` varchar(70) DEFAULT NULL,
  `itr2` varchar(70) DEFAULT NULL,
  `itr3` varchar(70) DEFAULT NULL,
  `itr4` varchar(70) DEFAULT NULL,
  `itr5` varchar(70) DEFAULT NULL,
  `itr6` varchar(70) DEFAULT NULL,
  `itr7` varchar(70) DEFAULT NULL,
  `itr8` varchar(70) DEFAULT NULL,
  `itr9` varchar(70) DEFAULT NULL,
  `itr10` varchar(70) DEFAULT NULL,
  `itr11` varchar(70) DEFAULT NULL,
  `itr12` varchar(70) DEFAULT NULL,
  `itr13` varchar(70) DEFAULT NULL,
  `itr14` varchar(70) DEFAULT NULL,
  `itr15` varchar(70) DEFAULT NULL,
  `for1` varchar(70) DEFAULT NULL,
  `for2` varchar(70) DEFAULT NULL,
  `for3` varchar(70) DEFAULT NULL,
  `for4` varchar(70) DEFAULT NULL,
  `for5` varchar(70) DEFAULT NULL,
  `for6` varchar(70) DEFAULT NULL,
  `for7` varchar(70) DEFAULT NULL,
  `for8` varchar(70) DEFAULT NULL,
  `for9` varchar(70) DEFAULT NULL,
  `for10` varchar(70) DEFAULT NULL,
  `for11` varchar(70) DEFAULT NULL,
  `for12` varchar(70) DEFAULT NULL,
  `for13` varchar(70) DEFAULT NULL,
  `for14` varchar(70) DEFAULT NULL,
  `for15` varchar(70) DEFAULT NULL,
  `q1` decimal(5,1) DEFAULT '0.0',
  `q2` decimal(5,1) DEFAULT '0.0',
  `q3` decimal(5,1) DEFAULT '0.0',
  `q4` decimal(5,1) DEFAULT '0.0',
  `q5` decimal(5,1) DEFAULT '0.0',
  `q6` decimal(5,1) DEFAULT '0.0',
  `q7` decimal(5,1) DEFAULT '0.0',
  `q8` decimal(5,1) DEFAULT '0.0',
  `q9` decimal(5,1) DEFAULT '0.0',
  `q10` decimal(5,1) DEFAULT '0.0',
  `q11` decimal(5,1) DEFAULT '0.0',
  `q12` decimal(5,1) DEFAULT '0.0',
  `q13` decimal(5,1) DEFAULT '0.0',
  `q14` decimal(5,1) DEFAULT '0.0',
  `q15` decimal(5,1) DEFAULT '0.0',
  `iu1` decimal(10,2) DEFAULT '0.00',
  `iu2` decimal(10,2) DEFAULT '0.00',
  `iu3` decimal(10,2) DEFAULT '0.00',
  `iu4` decimal(10,2) DEFAULT '0.00',
  `iu5` decimal(10,2) DEFAULT '0.00',
  `iu6` decimal(10,2) DEFAULT '0.00',
  `iu7` decimal(10,2) DEFAULT '0.00',
  `iu8` decimal(10,2) DEFAULT '0.00',
  `iu9` decimal(10,2) DEFAULT '0.00',
  `iu10` decimal(10,2) DEFAULT '0.00',
  `iu11` decimal(10,2) DEFAULT '0.00',
  `iu12` decimal(10,2) DEFAULT '0.00',
  `iu13` decimal(10,2) DEFAULT '0.00',
  `iu14` decimal(10,2) DEFAULT '0.00',
  `iu15` decimal(10,2) DEFAULT '0.00',
  `sc1` int(3) DEFAULT NULL,
  `sc2` int(3) DEFAULT NULL,
  `sc3` int(3) DEFAULT NULL,
  `sc4` int(3) DEFAULT NULL,
  `sc5` int(3) DEFAULT NULL,
  `sc6` int(3) DEFAULT NULL,
  `sc7` int(3) DEFAULT NULL,
  `sc8` int(3) DEFAULT NULL,
  `sc9` int(3) DEFAULT NULL,
  `sc10` int(3) DEFAULT NULL,
  `sc11` int(3) DEFAULT NULL,
  `sc12` int(3) DEFAULT NULL,
  `sc13` int(3) DEFAULT NULL,
  `sc14` int(3) DEFAULT NULL,
  `sc15` int(3) DEFAULT NULL,
  `imp_1` decimal(10,2) DEFAULT '0.00',
  `imp_2` decimal(10,2) DEFAULT '0.00',
  `imp_3` decimal(10,2) DEFAULT '0.00',
  `imp_4` decimal(10,2) DEFAULT '0.00',
  `imp_5` decimal(10,2) DEFAULT '0.00',
  `imp_6` decimal(10,2) DEFAULT '0.00',
  `imp_7` decimal(10,2) DEFAULT '0.00',
  `imp_8` decimal(10,2) DEFAULT '0.00',
  `imp_9` decimal(10,2) DEFAULT '0.00',
  `imp_10` decimal(10,2) DEFAULT '0.00',
  `imp_11` decimal(10,2) DEFAULT '0.00',
  `imp_12` decimal(10,2) DEFAULT '0.00',
  `imp_13` decimal(10,2) DEFAULT '0.00',
  `imp_14` decimal(10,2) DEFAULT '0.00',
  `imp_15` decimal(10,2) DEFAULT '0.00',
  `totale` decimal(10,2) DEFAULT '0.00',
  `n_tecnico` varchar(50) DEFAULT NULL,
  `data` date DEFAULT NULL,
  `pagamento` varchar(50) NOT NULL,
  `ultimamod` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `allegato` varchar(15) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

O
OsvaldoLaviosa
Super Famoso
Iscritto da
apr, 2012
Messaggi:
7493
Re: Normalizzare Database già in produzione
25 set 2018, 15:58
In questa sezione del forum si parla di "Progettazione database". Credo che la "normalizzazione" possa essere un elemento cardine.
Io ti consiglio di normalizzare "quella tabella". Vedo troppi campi con prefisso itr, for, q, iu, sc, imp (non capisco cosa significano nel tuo gergo professionale) che mi spingono a pensare che hai troppi valori espressi in ORIZZONTALE, mentre andrebbero esplicitati in VERTICALE, grazie a più tabelle correlate.
Azzardo un primo abbozzo di normalizzazione:
Clienti uno-a-molti Veicoli (perché un Cliente col passare del tempo potrebbe avere più Veicoli)
Veicoli uno-a-molti Riparazioni (ovvio)
C
ccuomo
Pochi posts
Iscritto da
apr, 2010
Messaggi:
33
Re: Normalizzare Database già in produzione
25 set 2018, 17:01
OsvaldoLaviosa ha scritto:
In questa sezione del forum si parla di "Progettazione database". Credo che la "normalizzazione" possa essere un elemento cardine.
Io ti consiglio di normalizzare "quella tabella". Vedo troppi campi con prefisso itr, for, q, iu, sc, imp (non capisco cosa significano nel tuo gergo professionale) che mi spingono a pensare che hai troppi valori espressi in ORIZZONTALE, mentre andrebbero esplicitati in VERTICALE, grazie a più tabelle correlate.
Azzardo un primo abbozzo di normalizzazione:
Clienti uno-a-molti Veicoli (perché un Cliente col passare del tempo potrebbe avere più Veicoli)
Veicoli uno-a-molti Riparazioni (ovvio)
Mi scuso per aver sbagliato sezione e mi scuso anche per il "gergo professionale" magari poco ortodosso
giusto per correttezza diciamo che:

itrx = intervento
forx = fornitore ricambio
qx = quantità
iux = importo unitario
scx = sconto
imp_x = importo

diciamo che il resto è abbastanza chiaro. Adesso avendo tutti i campi valorizzati su 5000 e più righe, normalizzare penso "nella mia ignoranza" non sia cosa semplice

Clienti uno-a-molti Veicoli (perché un Cliente col passare del tempo potrebbe avere più Veicoli)
Veicoli uno-a-molti Riparazioni (ovvio)
Per procedere come suggerito si presume che io dovrei avere una tabella clienti ed una tabella veicoli, tralasciando la parte fondamentale che non ho queste due tabelle, ma potrei crearle, il mio problema come mettere in relazione il tutto senza perdere l'attuale associazione cliente | targa | interventi eseguiti.

Naturalmente sono consapevole che non posso certo trovare risolvere il mio problema sul forum con quattro battute alla tastiera, ma già sapere che la cosa è fattibile mi sprona a farla cercando (magari grazie al vostro supporto la soluzione meno invasiva)
Toki
Moderatore
Iscritto da
gen, 2001
Messaggi:
3879
Re: Normalizzare Database già in produzione
25 set 2018, 17:27
ccuomo ha scritto:
Mi scuso per aver sbagliato sezione
Non hai sbagliato sezione.

ccuomo ha scritto:
mi turba che a lungo andare la dimensione della tabella espressa in Mb può raggiungere notevoli dimensioni. Allo stato attuale è pari e circa 2.5 Mb
Stai parlando di dimensioni irrisorie, inoltre 5000 records in una tabella sono "roba da niente" per MySQL.

ccuomo ha scritto:
il mio problema come mettere in relazione il tutto senza perdere l'attuale associazione cliente | targa | interventi eseguiti
Visto che per motivi che mi sfuggono ti vuoi imbarcare in quest'attività di normalizzazione:
Una volta creata la nuova struttura relazionale dovrai realizzare uno script sql/programma che effettui la migrazione dei dati dal vecchio al nuovo database. (Immagino sia questo il tuo cruccio).
Ti consiglio di riflettere comunque sulle problematiche relative alla gestione dello storico dei dati (se ti serve continuare ad averlo)
M
migliorabile
Super Famoso
Iscritto da
apr, 2013
Messaggi:
6045
Re: Normalizzare Database già in produzione
25 set 2018, 17:39
ccuomo ha scritto:
il programma fa esattamente quello che deve fare, mi turba che a lungo andare la dimensione della tabella espressa in Mb può raggiungere notevoli dimensioni. Allo stato attuale è pari e circa 2.5 Mb

Solo questo mi preoccupa
Megabyte per un MySQL e' come parlare della formica nei confronti dell'Everest.
5000 record sono un granello di sabbia sulla spiaggia

I problemi possono nascere quando le tabelle iniziano avere come dimensioni SVARATI GIGABYTE (dove per SVARIATI si parla di ALMENO 2GB, il limite e' 4GB), ed il numero di record si aggira attorno ai CENTINAIA DI MILIONI/MILIARDI.
E l'INSIEME DELLE TABELLE inizia ad avere SVARIATI TERABYTE (il limite e' 256TB oppure, con opportune configurazionei 65536TB)

Devi accedere o registrarti per scrivere nel forum

39 risposte