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

Reply via email to