Time of Update: 2018-12-07
現在有個構想:做一個程式員專用的IM,經過在論壇一番需求搜集:http://community.csdn.net/Expert/TopicView.asp?id=5221578http://community.csdn.net/Expert/TopicView.asp?id=5221507http://community.csdn.net/Expert/TopicView.asp?id=5221506現在進行部署,需求搜集繼續,我會及時公布相關的管理文檔,供大家參考,必然地也極其需要大家的建議,
Time of Update: 2018-12-07
要寫一種語言,我早有準備了,現在開始起草規格說明書,請路過的人都來參與。DD已經在ccrun.com做廣告了,應該知名度會逐漸上升的。雖然我已經廣發請帖徵求良方,可是還是孤身奮戰http://community.csdn.net/Expert/TopicView3.asp?id=4690611雖然我的前期作品也得到一定的肯定http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Duceland-Designer.shtml"
Time of Update: 2018-12-07
通知服務由所示組件組成。當事件提供者收集到事件後,會把這些事件一次全部提交給產生器,此操作作為一個交易管理,因此要麼全部事件提交,要麼全部放棄提交。在我們定義的ADF檔案中的每個事件,在組建通知服務執行個體後都會對應兩個表(NS<Event>EventBatches和NS<Event>Events),分別對應批與單個事件記錄。批表中有兩個欄位StartCollectionTime與EndCollectionTime分別對應一個批的開始建立時間與批記錄插入的完成時間。
Time of Update: 2018-12-07
因為上周準備不夠充分。關於過程的最佳化,還有一點想補充一下,上次的PPT中沒有加上這一部分,如有異議請指正。 /*這是對暫存資料表定義時的一段話: Once its creating level gets out of scope (terminates), a temporary table is automatically destroyed. If a temporary table was created in the outermost level, it is destroyed
Time of Update: 2018-12-07
資料庫設計中的忌諱閉環(closed
Time of Update: 2018-12-07
除了一些限制條件之外,參見ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.zh-CHS/tsqlref9/html/f1745145-182d-4301-a334-18f799d361d1.htm關於修改列的限制。對可進行修改的列進行修改時,應注意下面兩個問題:在對欄位長度進行調整時,會佔用大量系統資源。因此,不能在生產時間進行調整。在減小欄位長度時,會首先檢查原欄位中所有的記錄是否都在允許的範圍內,會進行表掃描。在增大欄位長度時,資料庫引擎會先建立一個物理表,把原表的記錄
Time of Update: 2018-12-07
顯示了一個SQL命令的執行過程,為了能使每個語句能高效的執行,我們應該盡量在關係層來完成所有的操作。舉個很簡單的例子:SELECT TOP 10 P.Name,P.Color,PSC.Name AS SubcategoryName,PC.Name AS CategoryName,D.DocumentSummary, PP.LargePhoto,SUM(LineTotal) LineTotal FROM Production.Product P JOIN
Time of Update: 2018-12-07
原始碼有點複雜,只是形式不用在意執行意義,它只是展示大部分所有的文法點:迴圈及其break和continue、goto、分支、try...catch等等,應有盡有。Code highlighting produced by Actipro CodeHighlighter
Time of Update: 2018-12-07
這要從ODS(Open Data Service)"開放資料服務"說起。它的主要職責是管理串連;SQL的線程服務和將結果集、狀態值及訊息發送給客戶。結果集使用TDS(Tabular data stream)表格式資料流進行傳送,它除了包含所需要的資料之外,還有一些描述資訊:如列名、類型、通訊的令牌等等。因此,這也是為什麼我覺得在預存程序中只返回一行記錄時,使用輸出參數能減少網路位元組數的原因,因為它少了很多其它要描述的資訊。 在資料庫的配置選項中,有對於Network
Time of Update: 2018-12-07
在新的SQLSERVER資料庫伺服器上線之前,我們在格式化硬碟時應該選擇配置單位的大小為64K,因為SQLSERVER的擴充分區大小是由8個8K的資料頁組成的。把配置單位大小設定為64K,可以減小索引的外部片段,在前面的文章中已經介紹過http://www.cnblogs.com/tom-fu/archive/2008/07/09/1238568.html。但這對硬碟的配置還是不夠徹底。每塊磁碟都有一個開機磁區,這個扇區預設是32K的大小。我們可以通過diskpart命令來觀察這個結果:
Time of Update: 2018-12-07
在使用索引對資料進行查詢時,最佳化器考慮是執行索引掃描還是索引尋找的依據是根據此索引相關的統計資訊。但統計的步長不能超過200(DBCC SHOW_STATISTICS返回的第三部分結果),這在資料量很大的表中,使得統計資訊的精度變得越來越不準確。當然,這個影響不會很致命,發生的機會也很少。關鍵是統計資訊得不到及時更新的話,就會使最佳化器選擇錯誤的執行計畫了。
Time of Update: 2018-12-07
不知道大家有沒有看過這篇文章(http://book.csdn.net/bookfiles/738/index.html),有兩個地方可能會誤導大家,在此說明一下的看法: 關於在程式中使用SqlParameter指定查詢參數後會被自動參數化,那我們可以放心拼接SQL嗎?
Time of Update: 2018-12-07
Widgets 引擎設計與實現一、背景和需求Widget 土名叫做小器件,在外國已經流行了很久了,Vista內建有之,Yahoo Widgets Engine 也存在和發展了很長時間了。那麼這個玩意兒在國內卻一直沒起色。究其原因,Widget 一般在看到案頭的時候才能看到,而大部分時間都在幹活的國人,自然沒有興趣使用 Widget 了。而且以其裝點案頭還不如玩玩遊戲呢。所以 Widget 到了中國必須換個臉面出現才有前途。Widget
Time of Update: 2018-12-07
現代網路的發展,越來越多的應用都搬到Internet上來了,強調使用者體驗。相應的編程需要開放性的語言,動態裝入,動態執行,遠程互動(互操作)。基於工程重用,又有了各種模式之說。所以對程式設計語言的不斷提出要求。雖然,筆者認為,C/C++已經夠好了,能滿足絕大多數的場合,那麼,是什麼動力促使Java,C#等語言推陳出新?是不是僅僅是上遊供應商的升級換代賺$的鬼使神差?還是廣大程式員的理所當然的要求呢?那麼,上遊供應商又吸收了原有的語言的特性上又整合了什麼“先進的功能”呢?這裡說這些顯然多餘的,因
Time of Update: 2018-12-07
Overview"Windows Presentation Foundation", "Windows CommunicationFoundation", and "Windows Workflow Foundation" are the names for threestrategic developer technologies that Microsoft plans to ship in 2006as part of the Windows Vista operating system.
Time of Update: 2018-12-07
看到有些預存程序在返回最後一次插入的行的編號時使用@@IDENTITY,這種做法很危險,在並發量大時會造成資料不一致問題,因此請使用SCOPE_IDENTITY函數。詳見聯機文檔的比較,另外還有一個IDENT_CURRENT。 簡單的說,SCOPE_IDENTITY只在當前範圍有效,比如一個預存程序中。IDENT_CURRENT返回的是一個表中最後受影響的編號,而@@IDENTITY則是針對整個資料庫有效。
Time of Update: 2018-12-07
通常,我們很容易觀察到資料庫伺服器的記憶體和CPU壓力。但是對I/O壓力沒有直觀的判斷方法。磁碟有兩個重要的參數: Seek time、 Rotational latency。正常的I/O計數為:①1000/(Seek time+Rotational latency)*0.75,在此範圍內屬正常。當達到85%的I/O計數以上時則基本認為已經存在I/O瓶勁。理論情況下,磁碟的隨機讀計數為125、順序讀計數為225。對於資料檔案而言是隨機讀寫,記錄檔是順序讀寫。因此,資料檔案建議存放於RAID5上,
Time of Update: 2018-12-07
資料檔案的片段 影響磁碟讀取效能的兩個主要因素:錄道時間和輪詢延遲。
Time of Update: 2018-12-07
關於資料庫中分頁的過程,網上大把。有通用的分頁預存程序,高效的分頁預存程序。但是,這些並沒有從根本上解決效能問題。我們知道對於相同的查詢,如果你限制每頁返回10條記錄和每頁返回20條記錄比,雖然10條記錄在網路和返回結果時會比20條記錄要稍稍佔一點優勢。但是它要花比20條記錄時2倍的訪問次數,因此從總的資源消耗來看10條記錄會佔用更多的資源。但是使用者的操作你永遠是無法預測的,它可能只是看了第1頁然後就退出了。我想一般使用者也很少會去查看第20頁之後的資訊吧,除非他是釣魚愛好者!因此,在確定每頁
Time of Update: 2018-12-07
所謂的ad hoc,中文譯作"即席查詢"。就是你使用 osql 或 sqlcmd 而不是作為遠端程序呼叫引用作為語言事件提交的 Transact-SQL,通俗點講就是你從SSMS命令視窗或是程式中拼接後直接發送的SQL語句就都是ad hoc,聲明一下這不包括那些聲明參數後,再通過參數執行的SQL語句。 使用ad hoc除了我們都很熟悉的SQL injection,帶來額外的網路開銷,不能很好的實現分層開發等不利之外。當你在程式中拼接的這些ad