dbExpress的設計問題

有誰知道（或關心做出suppostion爲）爲什麼將TSQLDataSet有的CommandText屬性（String），而TSqlQuery有SQL屬性（字符串列表）？dbExpress的設計問題

考慮sql語句

select id, name from 
table 
order by name

如果我使用一個TSqlQuery，那麼我就可以動態地訪問SQL更改查詢表名[1]，但如果我使用的是將TSQLDataSet（因爲我有到如果我需要一個bidrectional數據集，該數據集連接到服務提供商，然後到的TClientdataSet），我不得不從字面上設置在CommandText字符串。雖然上面的例子很簡單，但當sql語句涉及更多時，它可能會成爲問題。

更新：從目前的評論和答案來看，似乎我被誤解了。我不很在乎對於提高組件的運行時性能（什麼呢一毫秒無論何時查詢需要一秒鐘），但我做一下程序員（即我）並保持程序的能力照顧。在現實生活中，我有存儲在TSqlQuery以下查詢：我沒有算過字符串中的字符數

select dockets.id, dockets.opendate, customers.name, statuses.statname, 
dockets.totalcost, dockets.whopays, dockets.expected, dockets.urgent, 
(dockets.totalcost - dockets.billed) as openbill, 
(dockets.totalcost - dockets.paid) as opencost, 
location.name as locname, dockets.attention, 
statuses.colour, statuses.disporder, statuses.future, dockets.urgcomment 
from location, statuses, dockets left join customers 
on dockets.customer = customers.id 
where dockets.location = location.id 
and dockets.status = statuses.id

，但我敢肯定，有超過255個，因此排除將查詢存儲在一個簡單的字符串中。在某些情況下，我想通過添加'and statuses.id = 3'或'and customers.id = 249'行來過濾顯示的數據量。如果查詢存儲爲TStrings，那麼我可以在基本查詢中添加虛擬行'和1 = 1'，然後根據需要更新此行。但查詢是一個很長的字符串，我不能輕鬆訪問它的結尾。

我目前在做什麼（代替一個更好的解決方案）創造另一個將TSQLDataSet，並設置其CommandText爲默認將TSQLDataSet的CommandText，而附加額外的條件。

來源

2011-08-18 No' am Newman

如果考慮更改關於語句本身執行時間的SQL文本語句花費的時間，則更改整個SQL字符串不是問題。在所有情況下，整個SQL語句將被髮送到後臺數據庫驅動程序，所以這兩種方法都是等價的。（即使設置SQL [1]可能會稍微慢一點，如果'ParamCheck = true' - 請參閱da-soft答案）如果您想更快速地使用dbExpress，但不要使用dbExpress，而應使用直接數據庫訪問組件。 –

1）對不起，但這不是1ms。只要相信...... 2）自Delphi2以來，255不是Delphi字符串的限制。 3）您可以有效地使用作爲字符串的TStrings。我的答案有這一切。 –

爲了防止da-soft沒有清楚地說清楚; 1995年應用於德爾福1的255個字符串字符限制。它自1996年版本2.0起就沒有再應用於Delphi，並且這已經超過15年了！多行字符串可以在delphi屬性檢查器中編輯，如果他們有一個designtime「helper」註冊，在這種情況下，TSqlDataSet.CommandText已經在那裏供您使用。只需單擊屬性檢查器中的省略號按鈕即可獲得一個很好的SQL編輯器助手對話框。它不是RapidSQL或Toad，但它比使用1「寬的字符串屬性更好 –

1）TSQLQuery是相當與BDE的TQuery兼容性。而BDE TQuery具有SQL: TStrings屬性。 TSQLDataSet是應該用於新的應用程序。

2）雖然SQL: TStrings是有用的一些任務，也容易出錯。程序員經常忘記在再次填充之前清除SQL屬性。此外，如果您的查詢是一個大問題，填充SQL可能會導致性能下降。因爲每個SQL.Add(...)調用dbExpress代碼ParamCheck爲真時解析查詢。這可以通過使用BeginUpdate/EndUpdate或設置ParamCheck爲False來解決。但是請注意，將ParamCheck設置爲False會停止自動創建參數。

SQLQuery1.SQL.BeginUpdate; 
try 
    SQLQuery1.SQL.Clear; 
    SQLQuery1.SQL.Add('SELECT * FROM'); 
    SQLQuery1.SQL.Add('Orders'); 
finally 
    SQLQuery1.SQL.EndUpdate; 
end;

CommandText沒有這樣的問題。

3）您可以使用Format功能構建一個動態SQL字符串：

var 
    sTableName: String; 
... 
sTableName := 'Orders'; 
SQLDataSet1.CommandText := Format('select * from %s', [sTableName]);

4）其他數據訪問的庫，例如AnyDAC，有macro variables，簡化了動態查詢文本的建築。例如：

ADQuery1.SQL.Text := 'SELECT * FROM &TabName'; 
ADQuery1.Macros[0].AsRaw := 'Orders'; 
ADQuery1.Open;

來源

2011-08-18 05:19:26

」SQL的填充可能會導致性能下降「很吸引人......它是正確的：每當SQL調用」TSQLQuery.QueryChange「方法時.Add被執行，所以設置'ParamCheck = false'是一個好主意 –

-1

我不得不說TSqlQuery使用TString（Delphi 2010中的TWideStrings），因爲它更加靈活。

假設你的查詢是：

Select 
Item1, 
Item2, 
Item3, 
Item4 
FROM MyTable

這是一個更容易閱讀
您可以複製並粘貼到一個外部查詢工具，它保持格式化
很容易註釋掉部分

Select 
Item1, 
/* 
Item2, 
Item3, 
*/ 
Item4 
FROM MyTable

您可以輕鬆地添加項目

Select 
Item1, 
Item2, 
Item2a, 
Item2b, 
Item3, 
Item3a, 
Item3b, 
Item4 
FROM MyTable

嘗試這樣做，以連續的字符集永遠的推移一個長行與編輯窗口內不換行，始終是小的查看不允許包裝文本等等等等。等等。

只需0.02美元。

來源

2011-08-30 00:13:43

我完全同意我的問題，可能是什麼可能是設計問題，似乎選擇了字符串列表中的字符串 –

錯誤只需點擊省略號按鈕'[...]'在多行編輯字段中編輯屬性。僅僅因爲TStrings在頂層視圖中顯示'（Strings）'沒有理由認爲TStrings更好。 –

我點擊在設計時編輯字符串時的省略號按鈕我詢問查詢的運行時操作，查詢以字符串形式存儲時很難做到，而不是字符串列表。 –

dbExpress的設計問題

回答

相關問題