We recently published our second tutorial in our SQL Server 2008 spatial series SQL Server 2008 Spatial: Reproject data and More Spatial Queries. This one goes over transforming and loading data, quick look at analyzing plans and more simple spatial queries. We also put in links to other tutorials we found useful on the web.
In looking back at this, I noticed that we violated something. According to OGC spec, ST_PointN, STPointN - is only defined for LINESTRINGS and MULTIPOINTS, but SQL Server 2008 allows you to get away with using this for POLYGONS. If you try the same thing in PostGIS you will get null and I suspect the same holds true with DB2 and Oracle
I guess its somewhat debateable whether it is right to do more than what the spec says or not. Paul Ramsey mentioned (and I think he even changed in PostGIS trunk to have ST_NumPoints (which is only supposed to work for linestrings and multipoint?) to be an alias for ST_NPoints (which is not an OGC spec, but works for everything in PostGIS). STPointN/ST_PointN I guess is more arguable whether it should work for POLYGONS/MULTIPOLYGON because suppose for complex - its unclear what you would consider the order of points where rings are involved. I guess even there there is a natural order.
I suppose from a portability stand point its annoying to have things named the same or sort of the same that don't behave exactly the same across the databases you work with, but then again we don't live in an ideal world and who wants everything to be the same anyway? Where is the choice in that? So needless to say I am torn especially in cases where it seems the spec was short-sighted. ST_PointN/STPointN/ST_NumPoints/STNumPoints to me is one of those cases.
Anyrate stay tuned for the 3rd in our series.