[ASP.NET]ASP.NET 2.0中Membership的UserID問題

從ASP.NET 2.0開始，已經嘗試最大限度地將一些公用基礎設施統一起來，並引入了Provider模式！其中比較典型有Membership、Profile、Personalization等等，通過這些統一化的基礎設施，我們可以編寫少量代碼甚至不需要編寫任何代碼就可以達到以前費了九牛二虎之力才能實現的效果，而且這些代碼都是經過精密測試的，可以很大程度減少由於這方面代碼而引入的問題，所以對於部分網站而言，採用它們是比較經濟實惠的！

這裡要提及的是的Membership中的UserID問題，不知道出於什麼原因，Membership的相關資料表"aspnet_Users"等UserID的類型是uniqeidentifier，也就是說是128位的GUID，也許是為了簡單地保證唯一性吧！？但是在公司的既有項目和理想情況下，我希望使用的資料類型是int，特別是在電子商務類型的網站中，UserID和大量資料表比如訂單表等關聯，而且在統計查詢中大量使用到這個欄位，如果UserID是uniqueindentifier類型的話，相對int類型而言，查詢的速度將受到一定程式的影響（註：未測試），而且在某些時候UserID的作用類似於編號，可讀性比較好，在後台維護的時候有一定的便利。

反正不管是曆史原因還是什麼別的，我們現在需要的UserID必須是int類型！怎麼辦？ASP.NET提供的Membership中的UserID是uniqueidentifier已經是既成事實，我們無法改變！如果因為它的原因我們便完全拋棄這一套東西似乎又有一點可惜，經過考慮和參考DNN的實現，總結出如下兩種解決方案：

1. 在aspnet_Users表中添加一個類型為int的欄位BizUserID：具體的業務表都和BizUserID而不是UserID關聯，如果沒有重新實現MembershipProvider，那麼簡單起見，我們可以將BizUserID設定為自增長欄位！
2. 給aspnet_Users表建立一對一的關聯表Users，它們通過原來的UserID關聯，Users表另外提供一個類型為int的BizUserID欄位，業務表和該欄位關聯：DNN使用的就是這個方法，為了保持兩個表的同步，必須重寫MembershipProvider，有一定的工作量，但是由於引入了Users表，我們可以在其中儲存一些額外的資訊，特別是當你遷移遺留系統，這個方法還是比較簡單實用的。

在最後，我有個小小的疑問，不知道大家在實際項目中會直接使用Membership這一套東西呢，還是會自己實現一套新的？我沒有什麼項目經驗，比較好奇，想知道大家是怎麼選擇的，希望高人賜教！