Normalizzare Database già in produzione

di il
39 risposte

39 Risposte - Pagina 2

  • Re: Normalizzare Database già in produzione

    Onestamente, più che una tabella di un database, la tua tabella assomiglia più ad un foglio Excel.
    Il problema del campo targa è risibile in confronto a quello che ha fatto 'scoprire' Osvaldo!

    Ad essere onesti, metterci le mani per sistemare tutto significherebbe rifare tutto ex-novo (database + codice) con l'aggravante che hai già un bel po' di dati che poi dovresti riallineare/spalmare nelle varie tabelle.

    Sinceramente, a mio avviso, non ne vale assolutamente la pena perché sarebbe solo un bagno di sangue.
    Quando una cosa nasce sbagliata, non la sistemi più, e così bisogna tenersela.

    Come scriveva migliorabile, qualche campo doppio ci sta, a volte per comodità, a volte per scarse specifiche ricevuto in fase di progettazione, quindi il male è dei minori.
    Considerando che il tutto funziona, mi trovo quindi d'accordo con gli altri.

    Comunque rifare tutto utilizzando una più corretta normalizzazione ti sarebbe molto utile se non altro come un esercizio.
    Male non fa.

  • Re: Normalizzare Database già in produzione

    ccuomo ha scritto:


    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.
    1. Ogni tabella deve avere campi OMOGENEI che riguardano il nome stesso della tabella, ossia
    Clienti avrà i tipici campi anagrafici Cognome, Nome, Indirizzo, Telefono, Cellulare, e-mail...
    Veicoli avrà campi che riguardano solo ogni Veicolo, ossia Targa, Telaio, Marca, Modello…
    2. Ogni tabella deve avere un campo CHIAVE PRIMARIA (PK=PrimaryKey) che rappresenti UNIVOCAMENTE (come fosse una bandiera rappresentativa) un singolo record. Quindi dovrai aggiungere a Clienti un campo IDCliente di tipo "numerico progressivo automatico" (non so come si dice in MySQL).
    Idem dovrai avere un campo IDVeicolo nella tabella Veicoli.
    Solitamente i campi ID sono i primi della lista.
    3. I campi IDCliente, IDVeicolo che ti ho esposto avranno valori univoci nelle corrispondenti tabelle. Ma come devono apparire "molte volte"? Ecco che aggiungi un campo IDCliente (CHIAVE ESTERNA) dello stesso tipo dati, ma NON UNIVOCO, nella tabella Veicoli.
    Solitamente i campi chiave esterna (FK=ForeignKey) appaiono alla fine della lista campi.
    4. Adesso crei la relazione Clienti.IDCliente uno-a-molti Veicoli.IDCliente
    5. Similarmente devi ragionare per Veicoli uno-a-molti Riparazioni...sai tu i campi omogenei di Riparazioni.

    Mi sfuggono altri tuoi dettagli "professionali"...
  • Re: Normalizzare Database già in produzione

    Francamente sto ancora aspettando che qualcuno spieghi quali sarebbero gli ipotetici benefici di tale attività.
    È il classico esempio di approccio fideistico / didattico / dilettantesco.
    Comunque, visto che c'è sempre da imparare, in questo caso concreto quali sarebbero i miglioramenti?
  • Re: Normalizzare Database già in produzione

    gibra ha scritto:


    Onestamente, più che una tabella di un database, la tua tabella assomiglia più ad un foglio Excel.
    Il problema del campo targa è risibile in confronto a quello che ha fatto 'scoprire' Osvaldo!

    Ad essere onesti, metterci le mani per sistemare tutto significherebbe rifare tutto ex-novo (database + codice) con l'aggravante che hai già un bel po' di dati che poi dovresti riallineare/spalmare nelle varie tabelle.

    Sinceramente, a mio avviso, non ne vale assolutamente la pena perché sarebbe solo un bagno di sangue.
    Quando una cosa nasce sbagliata, non la sistemi più, e così bisogna tenersela.

    Come scriveva migliorabile, qualche campo doppio ci sta, a volte per comodità, a volte per scarse specifiche ricevuto in fase di progettazione, quindi il male è dei minori.
    Considerando che il tutto funziona, mi trovo quindi d'accordo con gli altri.

    Comunque rifare tutto utilizzando una più corretta normalizzazione ti sarebbe molto utile se non altro come un esercizio.
    Male non fa.

    Qualsiasi considerazione è sempre ben accetta e di fatto hai perfettamente ragione, più che ad una tabella di un database somiglia ad un foglio excel. Purtroppo questo succede quando si tende a "forzare la mano" cercando di voler fare qualcosa di buono (alle volte esigenza dettata dalla necessità, e non vado oltre...)

    Chissà, provero a ritagliarmi del tempo cercando anzitutto di studiare - pianificare - applicare quanto appreso, anzi colgo l'occasione per chiedere di essere indirizzato verso un percorso formativo (materiale) dove cominciare a studiare.
  • Re: Normalizzare Database già in produzione

    OsvaldoLaviosa ha scritto:


    ccuomo ha scritto:


    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.
    1. Ogni tabella deve avere campi OMOGENEI che riguardano il nome stesso della tabella, ossia
    Clienti avrà i tipici campi anagrafici Cognome, Nome, Indirizzo, Telefono, Cellulare, e-mail...
    Veicoli avrà campi che riguardano solo ogni Veicolo, ossia Targa, Telaio, Marca, Modello…
    2. Ogni tabella deve avere un campo CHIAVE PRIMARIA (PK=PrimaryKey) che rappresenti UNIVOCAMENTE (come fosse una bandiera rappresentativa) un singolo record. Quindi dovrai aggiungere a Clienti un campo IDCliente di tipo "numerico progressivo automatico" (non so come si dice in MySQL).
    Idem dovrai avere un campo IDVeicolo nella tabella Veicoli.
    Solitamente i campi ID sono i primi della lista.
    3. I campi IDCliente, IDVeicolo che ti ho esposto avranno valori univoci nelle corrispondenti tabelle. Ma come devono apparire "molte volte"? Ecco che aggiungi un campo IDCliente (CHIAVE ESTERNA) dello stesso tipo dati, ma NON UNIVOCO, nella tabella Veicoli.
    Solitamente i campi chiave esterna (FK=ForeignKey) appaiono alla fine della lista campi.
    4. Adesso crei la relazione Clienti.IDCliente uno-a-molti Veicoli.IDCliente
    5. Similarmente devi ragionare per Veicoli uno-a-molti Riparazioni...sai tu i campi omogenei di Riparazioni.

    Mi sfuggono altri tuoi dettagli "professionali"...

    Ciao OsvaldoLaviosa, l'impegno da te profuso nella spiegazione mi lascia ancora delle speranze, grazie al cielo esistono ancora persone che hanno la giusta "sensibilità" nell'aiutare chi è in difficoltà. Forte di questo e consapevole delle mie necessità e delle mie estreme carenze, proverò a sviluppare in un ambiente di test un tutto ex-novo riportando poi tutti i dati attualmente in produzione, cercando da qui a qualche mese di risolvere il mio problema e dando soddisfazione a chi ha creduto in me e mi ha supportato
  • Re: Normalizzare Database già in produzione

    +m2+ ha scritto:


    Francamente sto ancora aspettando che qualcuno spieghi quali sarebbero gli ipotetici benefici di tale attività.
    È il classico esempio di approccio fideistico / didattico / dilettantesco.
    Comunque, visto che c'è sempre da imparare, in questo caso concreto quali sarebbero i miglioramenti?
    Ciao +m2+,
    più scrivi più mi fai rendere conto e mi fai acquisire consapevolezza di essere un pischello se paragonato a te, ma per rispondere alla tua domanda, diciamo che i benefici si chiameranno (forse un giorno) "soddisfazioni personali"


  • Re: Normalizzare Database già in produzione

    Ahhh.. Messa in questi termini la domanda diventa articolata :
    0) cosa significa normalizzare?
    1) perché normalizzare?
    2) quando farlo?
    3) che vantaggi e che svantaggi avrò?
    4) scalerà?
    5) quanto costerà?
    Perché il metodo classico di insegnamento, anche universitario, è di tipo fideistico.
    si fa così perché è bene. Punto e basta.

    In realtà tutto ha effetti collaterali e costi, solo che - quasi sempre - non vengono insegnati.

    A scuola guida, ad esempio, si insegna che il freno a mano si usa come freno di stazionamento, punto e basta.

    Se fai un rally, anche tra dilettanti, lo userai invece praticamente sempre per controllare la imbardata.

    Non c'è quindi nulla di male nella normalizzazione, ma bisogna avere la consapevolezza che è un mero strumento e NON un fine.
    usualmente, se questo non viene insegnato, e normalmente non lo è, lo si impara dopo un 15 o 20 anni.

    Se vuoi avere un banale esempio di metodo di insegnamento 'cieco' basta chiedere quale sia l'algoritmo più veloce per ordinare N interi.
    dalle risposte si distinguono subito i dilettanti (anche laureati) dai professionisti (con o senza laurea).
    Come? Vediamo se qualcuno risponde qui e poi analizziamo le risposte
  • Re: Normalizzare Database già in produzione

    Poi ci sarebbe il pippone su campi autoincrementanti, cosa sono, perché usarli è perché Non usarli.
    di nuovo è la versione dilettanti vs professionisti.
    ma iniziamo con lo ordinamento di interi
  • Re: Normalizzare Database già in produzione

    Alé!!!

    +m+ è partito per la tangente.
    Divagazioni a go-go.
    Chi lo ferma più, adesso...


    P.S. Non ci avevi detto addio?
    Mi sono perso qualcosa?
  • Re: Normalizzare Database già in produzione

    gibra ha scritto:


    Alé!!!

    +m+ è partito per la tangente.
    Divagazioni a go-go.
    Chi lo ferma più, adesso...


    P.S. Non ci avevi detto addio?
    Mi sono perso qualcosa?
    Ti sei perso una caterva di messaggi di utenti affranti.
    magari c'è qualcuno cui piace imparare qualcosa che non sia una qualche autocomposizione access.

    Giusto per curiosità come ordineresti N interi?
  • Re: Normalizzare Database già in produzione

    +m2+ ha scritto:


    Ti sei perso una caterva di messaggi di utenti affranti.
    Allora chiedo scusa, non mi sono accorto della tua rentreé.
  • Re: Normalizzare Database già in produzione

    gibra ha scritto:


    +m2+ ha scritto:


    Ti sei perso una caterva di messaggi di utenti affranti.
    Allora chiedo scusa, non mi sono accorto della tua rentreé.
    Visto che, a tuo parere, sono partito per la tangente (il che, ovviamente, non è - al massimo per l'iperbole),
    giusto per curiosità come ordineresti N interi?

    Sembra una domanda semplice, ma le implicazioni sono tutt'altro che banali, e nello specifico proprio per questo thread.
  • Re: Normalizzare Database già in produzione

    Ccuomo è libero di imparare e sbagliare come meglio crede. Non siamo noi altri a dover giudicare il suo punto di vista, nemmeno scagliarci contro tra di noi. Ognuno è libero di fornire il proprio contributo come meglio crede/conosce/sa. Io spero di aver fatto del mio meglio.
    A questo punto mi pare di capire che ccuomo deve fare molti passi indietro, ossia IMPARARE a progettare un database. Questa cosa (generalmente) va di pari passo con l'imparare (su un manuale di base) una applicazione di programmazione per database. Su MySQL non sono in grado di aiutarti. Attendi congrui suggerimenti da chi la conosce bene e sa cosa suggerirti per iniziare.
  • Re: Normalizzare Database già in produzione

    Ma tu sei sicuro o comunque ritieni di saper progettare un database?
    E quale semantica vi attribuisci?
  • Re: Normalizzare Database già in produzione

    Calma, pace e serenità

    Il buon ccuomo avrà ormai capito che il suo database, vista la mole di dati trattati (assai modesta), potrà continuare ad essere utilizzato anche tra 10 anni senza che diventi un collo di bottiglia.

    Il buon ccuomo si è appassionato al modello relazionale e giustamente vuole imparare come affrontare e implementare la normalizzazione di un database.
    Non c'è nulla di male e sicuramente troverà stimolo nel partire da un database che conosce e che utilizza per lavoro.
    A mio avviso i commenti in questa discussione dovrebbero essere incentrati sul fornirgli dritte e consigli su come procedere.
    Per esempio:
    - gli si potrebbe indicare un libro "sintetico" che tratta l'argomento.
    - gli si potrebbe spiegare che nel mondo reale ci si ferma alla terza forma normale(3NF), salvo casi estremi . E' quindi inutile sbattere la testa sul resto.
    - gli si potrebbe spiegare perchè capita spesso di dover denormalizzare parti di un database
    - lo si potrebbe aiutare a sviscerare dubbi su singole tematiche

    E' inutile fare la gara a chi è più bravo o ne sa di più. In questo modo non si aiuta cuomo.
Devi accedere o registrarti per scrivere nel forum
39 risposte