微軟需要改進SQL Server的六大功能
很長時間以來,我一直在使用Microsoft SQL Server。最開始,我使用的是SQL 4.2,這是Sybase SQL Server 4.9的一個移植版本,運行在Windows for Workgroups 3.11系統上,這都是很久以前的事情了。從那以后,微軟的SQL產品已經走過了漫長的道路,而今年年底,微軟又將推出新版本的SQL 10.0,也就是被業界炒得沸沸揚揚的SQL Server 2008。經過這么多年的不斷完善,SQL產品肯定接近完美了,是不是?而事實并非如此。下面我就詳細介紹一下我希望微軟能夠改進的SQL 6大功能,但愿能夠在SQL Server 2008看到這些變化。
1.SSMS 自動刷新
在老版的企業管理器中,一件令人感到很討厭的事情是當你創建一個新的對象時,比如一個數據庫或一個表,您需要手動刷新對象資源管理器(Object Explorer),這樣才能看到新創建的對象。這種現象仍然存在于SQL Server Management Studio中,即使它在2005年被徹底重寫了,這件事情很惱人,因為你必須手動刷新包含新對象的那個文件夾。僅僅單擊“F5”是不會解決問題的。SSMS在后臺完成了那么多工作,那么,為什么不把這一功能交給SSMS來完成呢?
2.負載平衡的數據庫鏡像
當SQL Server 2005宣布具備數據庫鏡像(Database Mirroring)功能時,微軟承諾給我們一個數據保護和負載平衡的解決方案,不需要群集就能實現透明的故障和客戶端重定向。SQL Server 2008實現了幾乎所有這些功能,除了負載平衡。在故障發生之前,鏡像數據庫不得不處于“Restoring”或“No Recovery”模式下,這使得鏡像數據庫不能用于負載平衡查詢。的確,你可以對鏡像數據庫拍快照(snapshot),但是,這只是一個基于時間點的快照,并不能反映最新的數據庫更新。我認為這是由設計缺陷造成的。在修整這一缺陷之前,我不得不使用點對點復制(Peer-to-Peer Replication)或日志傳送(Log Shipping)進行負載平衡。
3. SSMS內置日志管理器(Log Explore)
通常,開發商對待事務日志(Transaction Log)的通用路線是,把它以某種內部或私有格式儲存,用戶無法查看或手動修改。如果你想要查看存儲在Transaction Log中的事務記錄,或者有選擇性重新執行某些事務而不擾亂其它事務的話,出你需要使用一個第三方的工具,比如Lumigent的Log Explorer。微軟應該將這種技術內置到SSMS中。微軟至今沒有收購該技術,這令我感到很奇怪。我猜想肯定是因為Lumigent要價太高了。也許要比收購雅虎的價格要便宜一些。
4. ReportBuilder RDL應該更為精確,以便能為BIDS提供更好的服務
ReportBuilder真的很酷,它能夠讓你使用報告模型非常迅速地創建強大的報告。你甚至可以讓你的用戶自己創建專案報告。或者把它放在你的口袋里,以便能在你預約體育鍛煉的空閑間隙快速地開發報告---想象一下,這會給你的用戶留下多么深刻的印象啊(開玩笑!)。ReportBuilder的神奇之處就在于它能生成RDL(報告定義語言),RDL是Report Services 中所有報告的XML源格式。這意味著你可以在Business Intelligence Development Studio (BIDS)中,用報表設計器(Report Designer)打開內置于ReportBuilder中的報告,從而進行進一步的修改和優化。除了BIDS數據集的定義不是很正確,需要進行一些人工干預來糾正這些錯誤。不過,微軟若要修改這一功能應該不會花費太多時間。
5.完整備份(Full Backup)應該截斷事務日志
自從SQL Server產品問世以來,完整的數據庫備份(Full Database Backup)是不截斷事務日志的。這意味著在全面修復模型(Full Recovery Model)下,事物日志會繼續無限增長,除非你經常單獨運行進行事務日志備份(Transaction Log Backups)。鑒于Microsoft Exchange Full Backup是截斷事物記錄的,所以我們為什么在SQL Server上也這么做呢?對于那些聽說微軟正在把SQL Server推進到“自我調整”模式的新用戶來說,這將是很有幫助的。
6.“開源”的報告管理器
內置在ASP.NET 2005中的報告管理器(Report Manager)是一個相當笨重的Web應用。不過現在,它在本地.NET代碼中被重寫了,所以我們不必使用IIS or ASP.NET。這簡直好極了。但是,把源代碼給我們,那么我們自己就能夠優化這個前端應用,這是不是太接近開源了?或許我們稱之為共享源代碼(Shared Source)更為準確。
