SQLite's data typing means it can support any and all field types supported in any other SQL database. That's a big deal. For the most part, the proper method for accessing any given data is going to be simple and universal. Homegrown routines will only happen if people have specific homegrown needs.
I'm a huge fan of strong typing, but I enforce that at the application level with wrapper classes for each table. I don't see a particular problem with SQLite's weak typing internally. SQLite has plenty of date editing routines. Dates are stored in a double as a Julian date. Check out the SQLite code to see how this was done. SQLite doesn't expose the date structure and routines at the C level (a major oversight IMO), so you'll need to lift the dates code and put it in a new public class. SQLite's understanding of "dates" is capable of supporting null, date, time, or datetime. The only real problem is that timezone is not stored, dates are always stored and retrieved in UTC, and dates with timezones are converted prior to storage. If you need to retain timezone you could replace all the date functions with your own version, and store the dates differently, or you could store the timezone separately. John -----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Ted Rolle Sent: Wednesday, October 28, 2009 1:57 PM To: sqlite-users Subject: [sqlite] Late data typing. Am I missing something? Doesn't dynamic data typing lead to bad data? And proliferation of home-grown editing routines? It seems that a strict data typing at column definition time would be MUCH better. For instance, date-editing routines... Ted _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users