Rappresentazione numeri decimali

di il
10 risposte

Rappresentazione numeri decimali

Buongiorno a tutti,
premetto che sono un quasi-neofita con SQL server e mi sto cimentando in una progettazione di un semplice db che dovrò integrare in una applicazione in Visual Studio, perciò perdonatemi per la domanda magari banale.
Ho un dubbio su come è meglio gestire dei numeri con virgola, nello specifico io devo trattare valori che cadranno in un range da +99999,999 a -99999,999 che però, in alcuni casi, potrebbero richiedere 4 decimali al posto di 3 (+99999,9999 -99999,999).
Trattandosi in realtà di quote da passare a macchine automatiche devono essere numeri precisi, perciò pensavo di utilizzare dei tipi decimal.
Ad es. decimal(5,4) non sapendo a priori se si tratterà di numeri a 3 o a 4 decimali.
La domanda è: secondo voi è il modo corretto di procedere? Perchè non ho ben chiaro come funzionerà l'approssimazione in SQL usando tipi real o float.
Ciao e grazie

10 Risposte

  • Re: Rappresentazione numeri decimali

    La domanda e' BANALE, ma la risposta e' DECISAMENTE complessa

    Comuqnue, in soldoni:

    ci sono DUE tipi di numeri con la virgola:

    1) quelli con un numero di decimali FISSO (in virgola FISSA) usati fondamentalmente per rappresentare soldi (moneta, schei, palanche, grana, pila, dine', dinari, ,..., currency). In questo caso tutti i conti vengono fatti in base 10, e quindi non ci sono problemi di arrotondamento (almeno per quanto riguarda somme e sottrazioni). I problemi nascono con moltiplicazioni e divisioni per numeri NON INTERI (per gli interi, non c'e' nessun problema). In questo caso, gli arrotondamenti vanno fatti secondo le indicazioni d ilegge (non so quali siano, ma so che ci sono)

    2) quelli con un numero di decimali VARIABILE (in virgola MOBILE, i classici float e double) usati fondamentalmente nel mondo scientifico CHE DOVREBBERO ESSERE EVITATI COME LA PESTE quando usati per rappresentare soldi. Questo per tutta una serie complicata di motivi uno dei quali e' che il numero NON E' RAPPRESENTATO IN BASE 10 ma in base 2, con tutte le conseguenze del caso, come ad esempio che certi valori dopo la virgola non possono essere rappresentati correttamente.

    Ora, dove sta' i problema?
    Ci sono diversi problemi:

    1) il DB e' in grado di rappresentare numeri in virgola fissa, ma non e' detto che il linguaggio di programmazione che usi sia in grado di farlo. Bisogna controllare ed eventualmente cercare una libreria specializzata per la rappresentazione di questo tipo di numeri

    2) il numero di programmatori che capiscono il problema si possono contare sulle dita della mano di un monco

    Per quanti riguarda la scelta tra decimale(X,3) o decimal(X,4) ovviamente decimal(X,4) va bene per entrambi i casi.
  • Re: Rappresentazione numeri decimali

    La risposta precedente è assolutamente condivisibile.
    Per la gestione lato applicativo, normalmente, si utilizza estesamente una funzione di arrotondamento\troncamento, del tipo
    euroarrotonda() o monetaarrotonda(valore,precisione) che richiamerai ovunque e quantunque, e soprattutto prima di scrivere i dati nel db
  • Re: Rappresentazione numeri decimali

    Grazie per le risposte decisamente esaustive.
    Come dicevo, si tratta di dati dimensionali che dovranno essere inviati a macchine, quindi gli arrotondamenti saranno alla terza (o quarta) cifra decimale. Ad esempio:
    Se il risultato di una operazione dovesse essere 1234,567887, potrà essere tranquillamente arrotondato a 1234,568 nel caso dei tre decimali o a 1234,5679 nel caso dei quattro decimali. Come dice +m+ questo è un problema da affrontare lato applicativo.
    In ogni caso, come immaginavo e come mi avete confermato, è meglio utilizzare numeri a virgola fissa lato DB.
  • Re: Rappresentazione numeri decimali

    Ho letto attentamente la discussione ma ho comunque paura di dire una stupidaggine; in questo caso vi prego abbiate pietà di me
    Volevo aggiungere che un modo alternativo è quello di lavorare con valori interi, quindi le varie quote moltiplicarle per 1000 prima del salvataggio su db: così se attualmente lavoro in metri, nel db salvo in millimetri. Nella mia piccola esperienza quando ho a che fare con misurazioni "salvo" sempre i dati come intero.
  • Re: Rappresentazione numeri decimali

    Tranquillo, non hai detto una stupidaggine. In effetti poi quando si inviano i dati alle macchine, spesso si usa questo "trucchetto", anche perchè i software dei PLC o dei controlli numerici a volte non gradiscono molto valori con virgola.
    Però in questo caso alcuni dei valori incriminati mi arrivano da apparecchiature che me li forniscono già in formato con decimali. Inoltre la mia applicazione che li preleverà (e scriverà) dal DB dovrà fare alcune operazioni e, se necessario, dovrà arrotondarli come spiegato prima.
    Inoltre l'operatore preferisce vedere i dati corretti, in questo caso i tratta di millimetri, e non in micron o decimi di micron.
  • Re: Rappresentazione numeri decimali

    Inoltre l'operatore preferisce vedere i dati corretti, in questo caso i tratta di millimetri, e non in micron o decimi di micron
    Il fatto che siano salvati in micron o decimi di micron nel db non vuol dire che a video tu non possa rappresentarli in millimetri, né che internamente tu non possa usare dei valori a virgola mobile per i tuoi calcoli. La trasformazione millimetri->micron va fatta al momento del salvataggio su db mentre il contrario micron->millimetri quando carichi valori da db.
  • Re: Rappresentazione numeri decimali

    Il fatto che siano salvati in micron o decimi di micron nel db non vuol dire che a video tu non possa rappresentarli in millimetri
    Si certo, ma che vantaggi avrei al posto di utilizzare dei decimal?
  • Re: Rappresentazione numeri decimali

    Si certo, ma che vantaggi avrei al posto di utilizzare dei decimal?
    Ripeto: spero di non dire stupidaggini e aggiungo che non mi sono mai interfacciato con SQL server nello specifico.
    Io riporto solo la mia esperienza personale: preferisco sempre "salvare" e poi "ricaricare" valori interi per il vantaggio di evitare problemi di compatibilità fra i vari ambienti, ovvero possibili "aggiustamenti" che possono essere introdotti a mia insaputa.
    Inoltre questo permette di non essere troppo "legato" ad una specifica tecnologia o prodotto rendendo più semplice il porting eventuale.
    D'altra parte lo stesso migliorabile (davanti al quale mi inchino) dice:
    1) il DB e' in grado di rappresentare numeri in virgola fissa, ma non e' detto che il linguaggio di programmazione che usi sia in grado di farlo. Bisogna controllare ed eventualmente cercare una libreria specializzata per la rappresentazione di questo tipo di numeri
  • Re: Rappresentazione numeri decimali

    candaluar ha scritto:


    Ripeto: spero di non dire stupidaggini e aggiungo che non mi sono mai interfacciato con SQL server nello specifico.
    Io riporto solo la mia esperienza personale: preferisco sempre "salvare" e poi "ricaricare" valori interi per il vantaggio di evitare problemi di compatibilità fra i vari ambienti, ovvero possibili "aggiustamenti" che possono essere introdotti a mia insaputa.
    Dipende se devi poi "interagire" con qualcosa di diverso, ad esempio un generatore di report "intelligente", generatori di chart e chi più ne ha ne metta.

    Aggiungo che gli altri due "giganteschi" problemi di portabilità sono i valori booleani (ma è facile usare interi 0/1), e soprattutto le date.
    Praticamente ogni db ha un "suo" formato strano per le date, e memorizzarle come stringhe (decodificandole da applicazione) è essenzialmente l'unico modo per non doverci fare "a cazzotti".
    Fino a quando (di nuovo) non devi usare qualche componente (es. report) e così via.
  • Re: Rappresentazione numeri decimali

    Dipende se devi poi "interagire" con qualcosa di diverso, ad esempio un generatore di report "intelligente", generatori di chart e chi più ne ha ne metta.
    Beh, in questo caso specifico no, nel senso che con il database interagirà solo il mio applicativo, quindi "lavo i panni sporchi in famiglia " date e orari compresi.
    Se poi in futuro si dovrà interagire con altri sistemi, questo vorrei sempre farlo tramite l'applicativo, nessuno andrà a ficcare il naso direttamente nel database, almeno questa è la mia idea.
Devi accedere o registrarti per scrivere nel forum
10 risposte