Disattiva la notazione scientifica nel client della riga di comando MySQL?

Question

Ho una tabella MySQL con molte colonne numeriche (alcune INT, alcune FLOAT). Vorrei interrogare con il client a riga di comando MySQL (specificamente, mysql Ver 14.14 Distrib 5.1.41, for debian-linux-gnu (x86_64) using readline 6.1), in questo modo:

SELECT * FROM table WHERE foo; 

Purtroppo, se il valore di ogni campo numerico supera 10^6, questo client visualizza il risultato in scientifica notazione, che rende difficile la lettura dei risultati.

Ho potuto correggere il problema FORMATANDO tutti i campi nella mia query, ma ci sono molti di loro e molte tabelle che vorrei interrogare. Invece spero di trovare una variabile o un flag client che posso impostare per disabilitare la notazione scientifica per tutte le query.

Non sono riuscito a trovarne uno nella pagina --help o nella pagina man, né a cercare su Google o su questo sito. Invece tutto quello che trovo sono le discussioni sulla conservazione/rimozione della notazione scientifica quando si utilizza l'API MySQL di <insert-programming-language>.

Grazie per eventuali suggerimenti.

:: :: completa

Ecco un esempio di tabella ...

mysql> desc foo; 
+--------------+-------------+------+-----+-------------------+ 
| Field  | Type  | Null | Key | Default   | 
+--------------+-------------+------+-----+-------------------+ 
| date   | date  | NO | PRI | NULL    | 
| name   | varchar(20) | NO | PRI | NULL    | 
| val   | float  | NO |  | NULL    | 
| last_updated | timestamp | NO |  | CURRENT_TIMESTAMP | 
+--------------+-------------+------+-----+-------------------+ 

e alcuni esempi di valori ...

mysql> select * from foo where date='20120207'; 
+------------+--------+--------------+---------------------+ 
| date  | name | val   | last_updated  | 
+------------+--------+--------------+---------------------+ 
| 2012-02-07 | A  |  88779.5 | 2012-02-07 13:38:14 | 
| 2012-02-07 | B  | 1.00254e+06 | 2012-02-07 13:38:14 | 
| 2012-02-07 | C  |  78706.5 | 2012-02-07 13:38:15 | 
+------------+--------+--------------+---------------------+ 

Ora, i valori reali ho caricato nella terzo campo sono:

88779.5, 1002539.25, 78706.5390625 

e possono essere visti esattamente se manipolo il valore:

mysql> select date, name, ROUND(val, 10), last_updated from foo where ... 
+------------+---+--------------------+---------------------+ 
| 2012-02-07 | A | 88779.5000000000 | 2012-02-07 13:38:14 | 
| 2012-02-07 | B | 1002539.2500000000 | 2012-02-07 13:38:14 | 
| 2012-02-07 | C | 78706.5390625000 | 2012-02-07 13:38:15 | 

Qualcosa nel client sembra essere far rispettare che mi è consentito soltanto per vedere sei cifre significative, anche se ci sono più nella tabella.

Se una query come

mysql> select ROUND(*, 2) from foo ... 

fosse possibile, sarebbe fantastico! Altrimenti non posso davvero prendere il tempo per racchiudere individualmente 100 nomi di colonne in "ROUND()" ogni volta che ho bisogno di ispezionare alcuni dati.

È interessante notare che di tanto in tanto utilizzo un'interfaccia phpMyAdmin per sfogliare il contenuto di alcune di queste tabelle e che l'interfaccia presenta anche questo limite di 6 cifre significative. Quindi non è limitato solo alla CLI.

Answer 1

Bene, dopo aver letto la documentazione in modo più approfondito, non riesco ancora a vedere alcun motivo per cui un client si limiterà a visualizzare solo 6 sig fichi da un FLOAT (specialmente quando il tavolo stesso sta sicuramente memorizzando di più).

Tuttavia, una soluzione accettabile (per questo utente stanco) è quella di cambiare tutti i miei tavoli per utilizzare DECIMAL (16,4) anziché FLOAT. Sfortunatamente, questo fa apparire tutti i miei numeri con 4 cifre decimali (anche se sono tutti '0'). Ma almeno tutti i numeri hanno la stessa larghezza adesso, e il mio cliente non li visualizza mai in notazione scientifica o limita il numero di sig fichi nel suo output.

Answer 2

La funzione CAST non consente di richiedere che i valori per un determinato campo vengano restituiti come DECIMALI?Non è un esperto e non l'ho provato, ma sarebbe la prima cosa che provo.