大約3年前我們開始使用COGNOS。我們已經使用了COGNOS 8，現在正在使用COGNOS 10.我們不斷被告知，使用動態SQL查詢而不是使用COGNOS模型是非常糟糕的，因爲它會導致性能問題，並且不推薦IBM。我們從未遇到特定於動態SQL的問題，它們的表現與使用該模型的報告一樣好。動態SQL與使用模型的對比
是否存在特定於動態SQL查詢的任何性能問題或缺陷？ IBM真的推薦它們不被使用嗎？
我知道該模型非常適合特別報告以及不知道SQL的用戶。但對於開發人員來說，動態SQL似乎是一個更好的選擇，特別是如果他們無法控制COGNOS模型。 （我們必須要求和記錄所需的更改模型）
欣賞您的意見/反饋。
使用動態SQL手動構建查詢可能由於許多原因（可擴展性，可維護性和可重用性）我們會變得更糟，但性能方面僅受限於您自己的SQL查詢編寫能力。這意味着在某些情況下，它會比使用Cognos模型更快。使用動態SQL沒有速度上的缺點。
這就是說，如果您沒有利用該模型，就會錯過Cognos的諸多好處。動態SQL將嚴重降低您保持一致性，進行廣泛更改而不重寫報表並快速生成新報表的能力。
如果您的環境很小，動態sql可能會滿足您的需求。特別是對於使用與您的其他報告無關的表格和關係的奇數一次性報告。或者，如果您希望強制使用索引的特定方式，則可以使用動態sql來實現。
編輯：重要的是要注意，Report Studio篩選器中建立的條件直到檢索到數據之後纔會傳遞到動態SQL查詢中。對於大型數據集，這可能效率極低。爲了從提示中將標準傳遞到動態SQL中，請使用#prompt（'yourPromptVariableNamehere'）＃或#promptmany（'yourMultiSelectPromptVariablehere'）＃＃。經驗法則是，在Cognos之外運行Dynamic SQL查詢並查看返回的數據量。如果您有一個巨大的銷售詢問，至少需要在日期或分支上過濾，請在提示頁面中放置提示以強制用戶選擇特定的日期/時間段/日期範圍/分支/等。插入到提示中，並使用提示/ promptmany語法將條件添加到動態SQL語句中。在Report Studio查詢中仍然可以將提示用作常規過濾器，但如果您在不使用prompt/promptmany的情況下使用動態查詢，則在從數據庫返回結果集之後過濾所有條件。
說到性能，當您引入動態SQL時，它將無法使用Cognos提供的緩存功能（系統方式）。
另一方面，很明顯，您可以比機器更好地調整SQL。 我不會說動態SQL可能會導致一般性能問題。
IBM不建議使用動態SQL，因爲只有使用適當的模型，才能使用框架管理器構建，您可以使用Cognos的所有功能。
對我有很多負面影響。你不能強制任何一致性。什麼能阻止我以與你完全不同的方式加入同一張桌子？維護是一場噩夢。如果數據庫中的某些內容發生變化，則必須在每個報告中更改它，而不是在模型中更改一次。我相信這也會阻止您利用Cognos中的一些新功能（DQM，動態多維數據集）。 – Andrew 2014-11-14 20:04:05
@Andrew - 感謝您的評論。我完全同意你在維護方面的問題，但從性能的角度來看，我真的只是在考慮這一點，並且在使用動態SQL時有任何性能缺陷。 – 2014-11-17 14:02:39
如果存在性能問題，則需要在模型中解決這些問題。 Cognos根據您創建的模型確定如何生成其SQL，因此如果出現問題，您可能需要投入一些時間來識別和解決模型中的問題。 執行您的建議實際上可能會進一步損害性能，因爲Cognos會發出元數據調用以檢索每次執行時查詢的每個列的詳細信息，正如Andrew所說，某些功能將失敗。 – chsh 2014-11-17 15:02:19