2010-07-12 75 views
3

我覺得這應該是一個很好的評論,但我覺得我所擁有的僅僅是一種分心。我是否正確地評論了我的這條查詢?

  1. 這是否值得評論?
  2. 如果是這樣,這個評論可以改進嗎?

請注意,我正在處理一個規範程度很差的應用程序。

( 
    /* Remove Time Portion From ActivityDate */ 
    DateAdd(Day, DateDiff(Day, 0, Activity.ActivityDate), 0) Not Between   
    /* Remove Time Portion From @MinimumDate Or SQL Server Min DateTime */ 
    DateAdd(Day, DateDiff(Day, 0, Coalesce(@MinimumDate, '1753-01-01')), 0) And 
    /* Remove Time Portion From @MaximumDate Or SQL Server Max DateTime */ 
    DateAdd(Day, DateDiff(Day, 0, Coalesce(@MaximumDate, '9999-12-31')), 0) 
) 
+1

你可能是最好的(如果這是在WHERE子句中),將@MinimumDate修改爲'該日期的午夜',並且@MaximumDate變爲'後一天的午夜',然後執行Activity.ActivityDate <@ MinimumDate或Activity.ActivityDate> = @MaximumDate - 如果你在ActivityDate上有一個索引,那麼這給了查詢優化器一個戰鬥機會。 – 2010-07-12 22:40:58

+0

@願意 - 現在這是一個好主意。 – ChaosPandion 2010-07-12 23:16:10

回答

1

我包裹DATEADD/DATEDIFF在一個標量UDF與自我註釋名稱,然後通過在Activity.ActivityDateCoalesce(@MinimumDate, '1753-01-01'))作爲參數

所以你有這樣的:

( 
    dbo.ufnGetDateOnly (Activity.ActivityDate) NOT BETWEEN   
     dbo.ufnGetDateOnly (COALESCE(@MinimumDate, '1753-01-01')) AND 
     dbo.ufnGetDateOnly (COALESCE(@MaximumDate, '9999-12-31')) 
) 

你可以也有一個「約會如果空」參數,並在UDF處理COALESCE如果它足夠常見的SQL代碼

( 
    dbo.ufnGetDateOnly (Activity.ActivityDate, DEFAULT) NOT BETWEEN   
     dbo.ufnGetDateOnly (@MinimumDate, '1753-01-01') AND 
     dbo.ufnGetDateOnly (@MaximumDate, '9999-12-31') 
) 

現在很明顯...沒有?

+0

當我處理你的典型語言時,這樣的事情會立刻變得明顯。有一件事要考慮,但是在處理大型結果集時性能會相當大。 – ChaosPandion 2010-07-12 22:26:28

+0

@ChaosPandion:一行標量udf既不存在也不存在,即使對於大型結果集也是如此。在這種情況下,希望只有每一行都能解析Activity.ActivityDate。我傾向於在查詢之前計算最小/最大值並使用局部變量... – gbn 2010-07-12 22:30:39

+0

好的,我該如何解釋看似神奇的空置換值。如果SQL Server具有某種我可以使用的功能,那就太好了。類似於'MaxValue(DateTime)''。然後我可以再將它包裝到一個函數中。 – ChaosPandion 2010-07-12 22:36:06

3

就個人而言,我覺得你不需要評論認爲說removes X from Yincrements X by Y等等

話雖這麼說,如果你覺得你需要註釋的代碼的特定部分,我嘗試着重於功能的意圖和大局。例如,爲什麼事情以這種方式實施?那樣的話,下一個跟在你身後的人會有一個戰鬥機會,當他必須做出改變的時候。例如,我知道你的代碼段的功能,但我不知道它爲什麼在那裏,或者它如何與應用程序的其餘部分相關。一個可能的改進可能是沿着某種功能的解釋的東西,你會給某個新的代碼或者可能不在乎的人它是如何實現的,但是爲什麼是

我總是不得不提醒自己,編程通信和更清楚你可以與其他程序員溝通你的意圖,你會更好。如果您可以找到一種方法來添加可以提高開發人員之間溝通質量的評論,那就去做吧。我認爲那些能夠準確告訴你代碼在做什麼的評論會起到反作用,最終會傷害溝通。

0

這些評論對我很有幫助,因爲如果他們不在那裏,我不得不考慮那些行是幹什麼的。雖然正如羅伯特格雷納所說,你爲什麼這樣做也很好知道。

0

不是記錄你做什麼。它必須是自解釋一行代碼所做的。文檔:

  • 塊的實現邏輯的主要作用是什麼? (例如函數,循環)
  • 約束,假設(空值?,線程安全?只讀?)
  • 爲什麼它是這樣而不是別的? (例如,體系結構決策,我們將使用這個XML解析,因爲我們需要名稱空間支持,並且因爲另一個不支持EBDIC編碼)
  • 這是一個大圖片嗎?它從哪裏來的?
  • 架構(包括DB約束,假設,如逃脫?)
  • 的影響(如安全性考慮,副作用)
  • 相關性(如圖書館,頁眉,在軟盤上一個神奇的鎖文件)