On 6 May 2013, at 1:14pm, Paul van Helden <p...@planetgis.co.za> wrote:
> My point was about not storing binary junk - the part of a number that has > no meaning because the accuracy of the inputs is limited. When you have a > generic db manager that can show any table or if you are looking at the > results of your own SQL statement, it helps to reduce clutter on the > screen. You should never be fetching a number from a database and showing it directly on the display. The number needs to be formatted by your software first. Does it need to be justified so a column of numbers lines up ? How should negatives be shown ? Do you want to show the decimal point as a comma or a stop ? Do you use a thousands separator ? Do you need a units symbol ? Formatting numbers for pretty printing is not the job of a database system. The database stores the numbers and recalls them for you. Figuring out how to show them onscreen is the programmer's job. You can format them after retrieving them from the database, or you can format them before retrieving them from the database before putting them in the database, in which case you should consider that you're storing strings, not numbers. > The data also compresses better. Not the way things are done these days. It's extremely rare to do semantic compression of individual values. Almost all compression methods just take the entire file in one go. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
