Normalizzare Database già in produzione

di
ccuomo
il
39 risposte
C
ccuomo
Pochi posts
Iscritto da
apr, 2010
Messaggi:
33

Normalizzare Database già in produzione

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

    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:
    7429

    Re: Normalizzare Database già in produzione

    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

    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:
    5873

    Re: Normalizzare Database già in produzione

    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

    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:
    7429

    Re: Normalizzare Database già in produzione

    Potresti elencare tutti i nomi campi della tua tabella?
  • +
    +m2+
    Utente Famoso
    Iscritto da
    mag, 2017
    Messaggi:
    3548

    Re: Normalizzare Database già in produzione

    ... 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

    +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

    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?
  • C
    ccuomo
    Pochi posts
    Iscritto da
    apr, 2010
    Messaggi:
    33

    Re: Normalizzare Database già in produzione

    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:
    7429

    Re: Normalizzare Database già in produzione

    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

    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
    Toki
    Moderatore
    Iscritto da
    gen, 2001
    Messaggi:
    3836

    Re: Normalizzare Database già in produzione

    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:
    5873

    Re: Normalizzare Database già in produzione

    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