假设我有一个用于查找项目的搜索屏幕。 屏幕上有各种可选的搜索选项,这些选项会导致 SQL 查询语句发生变化。
以下是一些搜索示例:
- 描述搜索
- 描述搜索 + 项目供应商 ID
- 描述搜索 + 项目供应商 ID + 项目层次结构级别 1 id
- 描述搜索 + 项目供应商 ID + 项目层次结构级别 1 id + 级别 2 id
- 项目层次结构级别 1 id + 级别 2 id(没有描述,没有物品供应商id)
...你明白了。 有相当多可能的组合。 我希望使用参数化查询来获得性能优势等(而且我在整个程序的其余查询中使用它们)。
有没有办法做到这一点,或者我是否被迫创建每个可能的查询和匹配的 SQLiteCommand 对象,或者根据所选选项使用 StringBuilder 动态构建查询字符串?
我正在将 SQLite.NET 数据提供程序与 C# 3.0(在 3.5 紧凑框架上)结合使用。
更新
基于一些参数为空默认值的建议并使用(@param isnull或column = @param)
,我想我应该能够得到这个上班。 我会及时向大家发布。
注意:我避免使用存储过程,因为代码的其余部分使用参数化查询而不是存储过程。 我希望保持一切一致,以保证未来维护程序员的理智。 无论如何,这应该不会产生太大的影响。
更新2
这在桌面系统上运行很棒(这是我对查询进行初始测试的地方)。 然而,在我使用的 Windows CE 设备上速度非常慢。 慢得无法使用。 尽管如此,我将来绝对可以使用它,而且非常方便。 只是在移动设备上运行查询时并非如此。
谢谢
Suppose I have a search screen that is intended for looking up items. There are various optional search options on the screen that will cause the SQL query statement to vary.
Here are some example searches:
- Description search
- Description search + item supplier id
- Description search + item supplier id + item hierarchy level 1 id
- Description search + item supplier id + item hierarchy level 1 id + level 2 id
- item hierarchy level 1 id + level 2 id (no description, no item supplier id)
...you get the idea. There are quite a number of possible combinations. I was hoping to use parameterized queries for the performance benefits and such (plus I'm using them for the rest of the queries throughout the program).
Is there a way to do this or am I forced to either create each possible query and matching SQLiteCommand object or build the query string dynamically with a StringBuilder based on the options selected?
I'm using using the SQLite.NET data provider with C# 3.0 (on the 3.5 compact framework).
UPDATE
Based on some of the suggestions with null default values for the parameters and using (@param isnull or column = @param)
, I think I should be able to get this to work. I'll keep you posted.
NOTE: I am avoiding using stored procedures because the rest of the code uses parameterized queries instead of stored procedures. I'd like to keep everything consistent for the sanity of future maintenance programmers. It shouldn't make too much of a difference anyway.
UPDATE 2
This worked great on a desktop system (which is where I did my initial testing for the queries). However, it was very slow on the Windows CE Device I was using. Unusably slow. All the same, I can definitely use this in the future and it's very handy. Just not when running queries on a mobile device.
Thanks
发布评论
评论(3)
从存储过程方面,您可以将默认值设置为 null,然后构建 where 子句来容纳该 null 值。
From the stored procedure side you can default values to null then build your where clause to accommodate this null value.
您可以分配参数默认值并处理存储过程中的逻辑:
处理存储过程主体中参数是否为空的逻辑。
You can assign the parameters default values and handle the logic within your stored procedure:
handle the logic of whether the parameters are null in the body of the sproc.
您最好为每种情况创建存储过程。
如果您在使用 StringBuilder 构建的 C# 中具有内联 SQL 代码,则执行计划将永远不会被缓存,并且其执行效果不会像存储过程那样好。
Your probably best off creating stored procedures for each case.
If you have inline SQL code in your c# built with a StringBuilder then the execution plans will never be cached and it will not perform as well as it would with stored procedures.