Bad design begins where you start throwing formatting functions in a SQL call that could be used as a calculated value. You request information for text, numbers, or blobs of binary data. Nothing more, nothing less, because it is assumed that you're going to do something productive with the number.
Bringing in "Other Database Engines do it!" discussion ultimately fails in that they only store data in one of three formats as well, and everything that comes to the UI is formatted for human consumption. Otherwise, you'd be given 1s and 0s for a 64-bit integer. And for those CLIs that output as numbers with commas and such? Thats still CLI and UI gravy, and not DB specific bloat. Any element that is to be portrayed to the users screen should be handled by whatever UI engine is displaying the information, not something that handles only three types of data. The UI needs to translate locality information. The date/time in your windows/linux/consoles/etc are presented to you formatted. The date and time are stored as a number, not "Friday, February 10, 2017 12:43:33pm". SQLite is lite. It is designed to be run on machines that have KILOBYTES of memory. Todays phones and devices that are all the rage do have MEGABYTES to GIGABYTES of memory and storage, sure, but there are devices out there that have literally KILOBYTES of data to be worked with. When you start adding beautification methods to something that needs to only provide three types of data, you're adding bloat, plain and simple. DRH isn't playing to the majority of machines, he's playing to machines that NEED to operate on ultra-low requirements. Rightly so. If the application of your choice isn't displaying the numbers as you want, take it up with the authors of the software that link into the engine. If its your program that is failing, change the UI elements to do the formatting for you. It'll be much easier to do math on a raw integer than a number that is converted between whatever kinds of different locales there are. Now, if you'd like, you could possibly throw a suggestion for the SQLite3 Client, sure, maybe with a particular command line option, or, even an option set in the CLI itself to format numbers to your OS's locale. But to have the SQLite3 engine start fart'n (ah-ha.. get it.. bloated? ... Wifes right, I'm so immature sometimes) out user specific formatting?? Yeah... Shouldn't be part of it. On Fri, Feb 10, 2017 at 11:13 AM, Dominique Devienne <ddevie...@gmail.com> wrote: > On Fri, Feb 10, 2017 at 4:44 PM, Hick Gunter <h...@scigames.at> wrote: > > First, SQLite is useful outside of purely embedded cases. > When it's embedded, sure, write your own UDF, and be done with it. > > But when you use SQLite to create databases to be viewed in any SQLite > client, > as is the case here, you're limited to what SQLite provides out-of-the-box. > The DB > in question are a mix of a few raw-data tables in human-unfriendly form, > and many > views which are human friendly and slice-and-dice the raw data for easy > analysis, > and such views use functions like datetime(), printf(), etc... > <cut> _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
