使用 linq-to-sql 和 xlinq 按 xml 列内容过滤数据库记录
我需要使用按 xml 类型列过滤来从数据库表中选择行。
表看起来像(简短版本)
id
dbfield int
xmlfield xml
,我以这种方式过滤它
IQueryable<Data.entity> q = from u in datacontex.entities
select u;
if (val1.HasValue)
q = q.Where( x => x.dbfield > val1.value)
if (val2.HasValue)
q = q.Where( x=> x.dbfield < val2.value)
if (!string.IsNullOrEmpty(searchString))
q = q.Where ( x=> x.xmlfield contains values from searchString)
xmlfield 中的 XML 非常简单,看起来像
<doc>
<item id="no">test/WZ/2009/04/02</item>
<item id="title">blabla</item>
...
问题是如何在 linq 中添加 WHERE 条件,最好这个条件应该转换为 ms-sql 查询,而不处理数据集在网络服务应用程序上。
谢谢。
I need to select rows from database table using filtering by xml-type column.
table looks like (short version)
id
dbfield int
xmlfield xml
and i'm filtering it in this way
IQueryable<Data.entity> q = from u in datacontex.entities
select u;
if (val1.HasValue)
q = q.Where( x => x.dbfield > val1.value)
if (val2.HasValue)
q = q.Where( x=> x.dbfield < val2.value)
if (!string.IsNullOrEmpty(searchString))
q = q.Where ( x=> x.xmlfield contains values from searchString)
XML in xmlfield is very simple it looks like
<doc>
<item id="no">test/WZ/2009/04/02</item>
<item id="title">blabla</item>
...
The question is how to add WHERE condition in linq and preferably this contition should translate to ms-sql query, without processing dataset on webservice application.
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
LINQ-to-SQL 不支持 TSQL 中的 xml 扩展。我看到两个选择:
where
子句中使用ctx.SomeUdf(row)
LINQ-to-SQL does not AFAIK support the xml extensions in TSQL. Two choices that I see:
ctx.SomeUdf(row)
in thewhere
clause of the LINQ您还可以在 SQL Server 表上创建计算列,从 XML 中提取这些点滴并将它们存储起来,就好像它们是表上的“正常”字段一样。我一直在生产系统的各个地方使用这种技术 - 效果很好。
执行此操作后,您可以像普通表字段一样使用它们,并且可以使用它们在 Linq-to-SQL 中进行过滤 - 没问题。
You could also create computed columns on your SQL Server table which extract those bits and pieces from the XML and store them as if they were "normal" fields on the table. I'm using that technique in various places all the time in production systems - works just fine.
After you do this, then you can use those like normal table fields and you can use them to filter in Linq-to-SQL - no problem.