有乙個演算法上的問題：
假設這有乙個各種字母組成的字串，假設這還有另外乙個字串，而且這個字串裡的字母數相對少一些。從演算法是講，什麼方法能最快的查出所有小字串裡的字母在大字串裡都有？
比如，如果是下面兩個字串：
string 1: abcdefghlmnopqrs
string 2: dcgsrqpom
答案是true，所有在string2裡的字母string1也都有。如果是下面兩個字串：
string 1: abcdefghlmnopqrs
string 2: dcgsrqpoz
答案是false，因為第二個字串裡的z字母不在第乙個字串裡。
對於這種操作一種幼稚的做法是輪詢第二個字串裡的每個字母，看它是否同在第乙個字串裡。從演算法上講，這需要o(n*m)次操作，其中n是string1的長度，m是string2的長度。就拿上面的例子來說，最壞的情況下將會有16*8 = 128次操作。
乙個稍微好一點的方案是先對這兩個字串的字母進行排序，然後同時對兩個字串依次輪詢。兩個字串的排序需要(常規情況)o(m log m)+ o(n log n)次操作，之後的線性掃瞄需要o(m+n)次操作。同樣拿上面的字串做例子，將會需要16*4 + 8*3 = 88加上對兩個字串線性掃瞄的16 + 8 = 24的操作。(隨著字串長度的增長，你會發現這個演算法的效果會越來越好)
最終，我們可以找到乙個最佳的演算法，只需要o(n+m)次操作。方法就是，對第乙個字串進行輪詢，把其中的每個字母都放入乙個hashtable裡(成本是o(n)或16次操作)。然後輪詢第二個字串，在hashtable裡查詢每個字母，看能否找到。如果找不到，說明沒有匹配成功。這將消耗掉8次操作——這樣兩項操作加起來一共只有24次。不錯吧，比前面兩種方案都要好。
通常來說這是比較合理的演算法，也是最正常的邏輯。但如果你想做到別人做不到的，往往就需要讓自己具有跳躍性的思維方式，例如下面這種演算法：
假設我們有乙個一定個數的字母組成字串——我給每個字母分配乙個素數，從2開始，往後類推。這樣a將會是2，b將會是3，c將會是5，等等。現在我遍歷第乙個字串，把每個字母代表的素數相乘。你最終會得到乙個很大的整數，對吧？然後——輪詢第二個字串，用每個字母除它。如果除的結果有餘數，這說明有不匹配的字母。如果整個過程中沒有餘數，你應該知道它是第乙個字串恰好的子集了。這樣是不是更好？
如果你想到了多數人想不到的，就可能獲得多數人達不到的成就。
同事的評價 你的思維跳躍性太大！
前幾日，產品研發部個同事跟我講，公司有同事說你的思維跳躍性太大 當時我笑了笑，順便問了一句，應該是貶義吧，呵呵 同事點頭確認 今日，想起此事，並沒太在意，回想創業快一年之久了，自己做事比較將事物的客觀性和邏輯性，從同事的評價中只有兩點是可以肯定的 1 我的思維跳躍性的確大，但是這個跳躍是有具體路徑的...
具有包含性列的索引
在 sql server 2005 中，可以通過將非鍵列新增到非聚集索引的葉級別來擴充套件非聚集索引的功能。通過包含非鍵列，可以建立覆蓋更多查詢的非聚集索引。這是因為非鍵列具有下列優點 當查詢中的所有列都作為鍵列或非鍵列包含在索引中時，帶有包含性非鍵列的索引可以顯著提高查詢效能。這樣可以實現效能提公...
建設性的思維
仔細一想，生活中 工作中，我做到了嗎？好像不多，很多時候根本就沒有這個意識。現實中人人都是批評家，都很會挑毛病，言辭乙個比乙個犀利。但是有多少人在提出問題後，仔細分析了產生問題的原因，又有多少人本著善意和誠意提出了自己的建設性意見或建議呢？答案是很少，至少我感覺是。在我們的身邊都充斥著太多的批判式思...