我經常想，在對空間信息的支持上，由于它缺乏對幾何體的存儲， mssql 總是比別的數據庫慢了一拍。在新的 .net clr 的支持下，你可以真正地添加你自己的基于 .net 的對象。盡管我也試了下在 sql server 中實現簡單幾何類型的存儲，但有一些限制使我不得不放棄了嘗試。首先，用戶數據類型不能超過 8000 字節。也就是說，幾何體對象不能超過 500 個節點，這對像海岸線這樣的對象就顯得太少了。另一個問題是 sql server 不支持繼承，所以你也不能對你的數據類型做比較好的面向對象實現。

　　...所以昨天我試著找到了一個完全不同的更簡單的實現。我決定以 well-known binary 的形式（譯者注： opengis 的說明書中定義了兩個表述空間對象的標準方式：一個是 wkt （ the well-known text ）形式，另一個是 wkb （ the well-known binary ）形式）存儲幾何體在一個圖像列中。使用圖像列的目的是它能夠保存大到 2g 的數據，這對大多數的幾何對象都足夠了。而字節列和用戶自定義類型一樣，也有 8000 個字節的限制，所以也不夠好。除了幾何列之外，我還創建了四個實數類型的列，用來存儲幾何外接矩形框的最大最小坐標值。這能提高基于外接矩形框的查詢的效率。其它的列用來存儲幾何體的屬性。

　　我在 sharpmap 中實現了這個方法。首先，我建立了一個小的數據庫導入程序用來導入 shapefile 文件。它在數據庫中建立一個表，然后把幾何體及其對象導入其中。 sharpmap 為其提供了必要的數據讀取器和 wkb 格式化程序。第二個部分是建立了一個數據提供接口， sharpmap 能夠基于這個接口繪制數據。我做這些時多少參照了 postgresql/postgis 的數據提供接口，只是用四個外框坐標列來做外接矩形框查詢。所有這些工作所發費的時間不超過一個小時，因此，可以說做起來是比較簡單的。

　　我必須說，對于這種方法的效率我是很驚訝的。它比 shapefile 的數據接口還快一點點，而 shapefile 數據接口曾經是 sharpmap 中最快的數據接口。而 postgresql/postgis 相比而言要慢 4 － 6 倍。