1.關於使用schema有兩種用法
第一種，每個專案建乙個schema資料庫和乙個缺陷資料庫，這個專案的缺陷庫對應這個專案的schema，與其它專案無關。所以，更改這個專案的schema不影響其它專案的schema，可以根據需要隨便更改。
第二種，建乙個公共的schema資料庫，所有專案的缺陷資料庫都用這個公共的schema資料庫，如果其中某乙個專案確定要對schema更改，則是對所有專案schema的更改。
我們公司現在用的是第二種，這樣有可能就會出現乙個問題，某乙個專案確定schema要更改，而其它專案並不需要更改後的，而是要用schema以前的版本。
下面是解決辦法：
schema在變更的過程中產生了許多版本，假如有5個版本，a和b兩個專案目前都使用的是最新的第5版本，現在專案a要求更改shema，而專案b還是使用版本5。這時，根據專案a的要求對schema進行修改，check in後schema公升級到版本6，公升級a專案的缺陷資料庫使用版本6的schema即可，不要公升級專案b的缺陷資料庫。
如果又來了乙個新的專案
c，要求使用
schema
的第三個版本，則在
cq designer
連線schema
和專案c
的缺陷資料庫時，選擇
schema
的第三個版本即可。
一般來說既然使用了第二種方法，最好是所有專案都使用同乙個版本的schema，方便管理，如果有不同專案使用了不同版本的schema，應該有個文件來記錄哪個專案使用的是哪個版本的schema；
如果有個專案對schema的要求特別特殊，它對schema的改動後的結果不適合其它專案，最好是單獨為它建乙個schema資料庫，這樣就不會影響到其它專案。
另外，如果乙個
schema有5
個版本，如果只想匯出其中的第
3個版本，這樣是不能實現的，在
sql server
中備份資料庫的時候，實際上是把1到
5版本都匯出來了，還原進新的
schema
資料庫自然也是1到
5版本；
如果此時想在版本
3的基礎上修改
schema
，這樣也是不能實現的，現在最新的版本是版本
5，只能在版本
5的基礎上修改，之前的版本
3就只能檢視不能修改了。
關於巨集需要注意的問題
關於巨集需要注意的問題 1 define巨集與函式之間的優劣 巨集的執行速度比函式快得多，函式需要呼叫 返回等操作。函式只能對特定的型別操作，而巨集是型別無關的，巨集還可以實現一些函式無法實現的操作。但巨集需要將所有 拷貝到呼叫程式中，增加了 長度。所以 巨集比較適合執行簡單的計算，如求2個值中的較...
關於sql server建立索引需要注意的問題
人們在使用sql時往往會陷入乙個誤區，即太關注於所得的結果是否正確，而忽略了不同的實現方法之間可能存在的效能差異，這種效能差異在大型的或是複雜的資料庫環境中 如聯機事務處理oltp或決策支援系統dss 中表現得尤為明顯。筆者在工作實踐中發現，不良的sql往往來自於不恰當的索引設計 不充份的連線條件和...
關於Map Set list集合需要注意的地方
一 非空判斷 如果object為null，則設定為defaultvalue objectutils.defaultifnull object,defaultvalue 判斷集合是否為null listlist new arraylist system.out.println list.isempty...