使用 EF4.0 / LINQ 对枢轴 3NF 数据进行建模

发布于 2024-10-17 05:01:12 字数 438 浏览 3 评论 0原文

我目前正在开发一个项目,该项目几乎所有业务逻辑都封装在数据库(SQL Server)中,现在需要完全删除数据库依赖项。

我在数据库中有一些规范化数据,格式为:

Record [RecordID, RecordTypeID, OwnerID, RecordValue] RecordType [RecordTypeID, Description]

在 RecordTypeID 之间具有外键。我想做的是强类型记录集;数据库中存在对数据进行 PIVOT 的查询,因此我得到的记录集为:

TypedRecord [RecordType1Value、RecordType2Value、RecordType3Value...]

但显然无法在该项目中使用 PIVOT 命令。谁能提出解决这个问题的适当策略?我们将使用 .NET 4.0(包括 EF4.0),因此 linq 解决方案就可以了。

I'm currently working on a project that has almost all of its business logic encapsulated in the database (SQL Server) and now have a requirement to remove the database dependency entirely.

I've got some normalised data in a database in the form:

Record [RecordID, RecordTypeID, OwnerID, RecordValue]
RecordType [RecordTypeID, Description]

with a foreign key between RecordTypeIDs. What I want to do is strongly type the record set; there are queries in the database that PIVOT the data so I get a record set as:

TypedRecord [RecordType1Value, RecordType2Value, RecordType3Value...]

but obviously can't use the PIVOT command in this project. Can anyone suggest an appropriate strategy for tackling this? We'll be using .NET 4.0 (inc EF4.0) so linq solutions would be fine.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

自演自醉 2024-10-24 05:01:12

删除“数据库依赖”是个好主意,但显然您有大量面向数据的应用程序,因此您应该考虑一些方面。即使使用 EF,使用 SQL 进行高级查询仍然很有用 - PIVOT 就是这样的例子。不要删除这些查询,否则您将必须直接在应用程序的内存中计算透视数据 = 将所有相关数据从数据库传输到应用程序并计算透视聚合。

EF4 提供了多种调用传统 SQL 的方法。正确的方法可能是将查询封装到存储过程中并使用它们。

It is nice idea to remove "database dependency" but obviously you have heavy data oriented application so you should consider some aspects. Even with EF it is still useful to use SQL for advanced queries - PIVOT is such example. Don't remove these queries or you will have to compute pivoted data directly in memory of your application = transfer all related data from db to application and compute aggregations for pivoting.

EF4 offers several ways to call tranditional SQL. The way to go is probably encapsulating your queries into stored procedures and use them.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文