Table driven, massively parallel RDBMS in the future
Date: 10 Feb 2007 10:03:07 -0800
Message-ID: <1171130586.993856.71690_at_p10g2000cwp.googlegroups.com>
Troels Arvin posted a probelm in the DB2 newsgroup in which he had a data source with CHAR (n) data that was supposed to be in ISO-8601 format (i.e '2006-12-24') which are to be converted to DATE values.
One solution proposed was to used an internal User Defined Function
(UDF) or an external UDF to validate the string: So I'm looking for
having a CAST to a temporal type; if the cast fails, return NULL.
Some of the values are known to be invalid (such as '0000-00-00' or
'2006-02-45').
Lennart proposed that Arvin use a calendar table instead of computational code, expressing the dates as CHAR(n) strings for the last century (good enough for the problem), or about 4000 rows. This idea should work for other scenarios as well.
My next book deals with table-oriented solutions rather than computational solutions to DB problems. If anyone has more tips like this, please send them to me.
My model of the future of RDBMS is that we will have multi-core chips
(INTEL is promising 80 in the near future) combined with secondary
storage that has the seek times of current semi-conductor primary
storage. This will make massively parallel RDBMS the norm.
Decades ago Jerry Pournelle predicted that we would have one processor per task in a system (he was thinking about smart printers or the new IBM tape drive that has encryption). I am starting to see the day when we have one processor subset of a table (or per row!!), which pass their results up a hierarchy that mimics a parse tree, all done in parallel.
In this case, each of the 80 processors handles about 50 date strings. Your refrigerator CPU handles more data than that!
Comments? Feedback? Better yet, code and examples? Received on Sat Feb 10 2007 - 19:03:07 CET