Normalizzare Database già in produzione

ccuomo

il 25 set 2018, 09:09

39 risposte

39 Risposte - Pagina 2

gibra
Molto attivo
Iscritto da
gen, 2013
Messaggi:
1647
Re: Normalizzare Database già in produzione
25 set 2018, 17:41
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.
O
OsvaldoLaviosa
Super Famoso
Iscritto da
apr, 2012
Messaggi:
7500
Re: Normalizzare Database già in produzione
25 set 2018, 17:54
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"...
+
+m2+
Utente Famoso
Iscritto da
mag, 2017
Messaggi:
3548
Re: Normalizzare Database già in produzione
25 set 2018, 19:14
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?
C
ccuomo
Pochi posts
Iscritto da
apr, 2010
Messaggi:
33
Re: Normalizzare Database già in produzione
26 set 2018, 09:59
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.
C
ccuomo
Pochi posts
Iscritto da
apr, 2010
Messaggi:
33
Re: Normalizzare Database già in produzione
26 set 2018, 10:02
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
C
ccuomo
Pochi posts
Iscritto da
apr, 2010
Messaggi:
33
Re: Normalizzare Database già in produzione
26 set 2018, 10:05
+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"
+
+m2+
Utente Famoso
Iscritto da
mag, 2017
Messaggi:
3548
Re: Normalizzare Database già in produzione
26 set 2018, 10:17
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
+
+m2+
Utente Famoso
Iscritto da
mag, 2017
Messaggi:
3548
Re: Normalizzare Database già in produzione
26 set 2018, 10:20
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
gibra
Molto attivo
Iscritto da
gen, 2013
Messaggi:
1647
Re: Normalizzare Database già in produzione
26 set 2018, 10:27
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?
+
+m2+
Utente Famoso
Iscritto da
mag, 2017
Messaggi:
3548
Re: Normalizzare Database già in produzione
26 set 2018, 11:25
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?
gibra
Molto attivo
Iscritto da
gen, 2013
Messaggi:
1647
Re: Normalizzare Database già in produzione
26 set 2018, 11:57
+m2+ ha scritto:
Ti sei perso una caterva di messaggi di utenti affranti.
Allora chiedo scusa, non mi sono accorto della tua rentreé.
+
+m2+
Utente Famoso
Iscritto da
mag, 2017
Messaggi:
3548
Re: Normalizzare Database già in produzione
26 set 2018, 12:03
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.
O
OsvaldoLaviosa
Super Famoso
Iscritto da
apr, 2012
Messaggi:
7500
Re: Normalizzare Database già in produzione
26 set 2018, 19:56
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.
+
+m2+
Utente Famoso
Iscritto da
mag, 2017
Messaggi:
3548
Re: Normalizzare Database già in produzione
26 set 2018, 20:05
Ma tu sei sicuro o comunque ritieni di saper progettare un database?
E quale semantica vi attribuisci?
Toki
Moderatore
Iscritto da
gen, 2001
Messaggi:
3886
Re: Normalizzare Database già in produzione
27 set 2018, 08:31
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