SQL Server 2008 will contain, if my count is correct, 7 new data types. Note: none of these are in the current CTP.
DATE – ANSI-compliant date data type
TIME – ANSI-compliant time data type with variable precision
DATETIMEOFFSET – timezone aware/preserved datetime
DATETIME2 – like DATETIME, but with variable precision and large date range
GEOMETRY – "flat earth" spatial data type
GEOGRAPHY – "round earth" spatial data type
HIERARCHYID – represents hierarchies using path enumeration model
The first four (date/time series) are NOT implemented/exposed as .NET system UDTs, but the last three are exposed as .NET system UDTs. This means that, for the first time, .NET will be used as part of SQL Server. In SQL Server 2005, there were originally DATE and TIME data types implemented in .NET, but implementing temporal data is an intricate process. After much wailing and gnashing of teeth by some members of the user community, these were removed. One of the complaints was the .NET implementation. Hmmm…
One of the nice side-effects of implementing spatial and hierarchyid as .NET types is that these will be shipped as a separate assembly, and that the types will be available for client-side and middle-tier use as well as in the database. So if you want to do some massive number crunching of spatial sequences on a computation server and the network traffic from database to computation server is acceptable, you can do so.
In general, SQLCLR makes the "logic in database or middle-tier" argument easier to deal with. Although there's no "run on database or run on server" switch in VS, with minimal code changes you can move your logic, or even duplicate the logic between tiers if need be. You can't do this with T-SQL; although its faster and better for data access on the database, it doesn't run outside the database. Unless you want to use SQL Server Express Edition as an application server. But that's a discussion for another time.