2

我已经开始从事金融服务行业的一个项目，该项目（主要）基于 SQL Server (2000)、ColdFusion (8) 和一些 Access/.NET 应用程序。这个项目从一些简单的 Access 表单/VBA 开始，然后慢慢转换为 Web 界面。

我可以说数据库设计和应用程序编码是由在工作中学习的人完成的，并且从一开始就没有机会学习好的设计原则。许多业务规则设置在无数级联函数和存储过程以及 Web 服务器模板中。在使用未注释常量的复杂 500 行 SQL UDF 中有大量特殊情况处理。跟踪查询中可能涉及的 10-20 个 UDF 之间的所有交互是非常困难的。一些查询似乎需要很长时间才能运行（最多 15 分钟）。

虽然这些表的索引相当好，但缺乏 FK 关系并且几乎没有参照完整性。数据库很少更新，每天都有少量的批量（多个表中的 1,000 条记录）。它主要用作数据存储库 - 我想是数据仓库。我们很少遇到死锁或延迟。

所以，我的问题是：如果我想重新实现整个项目，包括数据库和前端，看看非关系实现是否有意义？主数据库只有大约 1GB (.mdf)，因此可以轻松放入内存中。我想从 SQL 查询结构转移到一些可以有效编译和执行的声明性模型。如有必要，我可以将 SQL DB 用作数据存储。

4

2 回答 2

1
  • 如果我想重新实现包括数据库和前端在内的整个项目，那么查看非关系实现是否有意义？

总的来说，大多数开发人员，即使是那些呼吸 map/reduce 并穿着 NoSQL T 恤的开发人员，对 SQL 感觉更舒服。

如果您的应用程序遵循经典的 MVC/MVP 模型，那么大多数框架（例如 Spring、Rails、Grails、Django、Webmachine 等）实际上都带有对 SQL 后端的一流支持。还有一些对 NoSQL 的支持。

如果您没有看到 NoSQL 可以为您的系统带来任何实际好处（这是我发布到另一个问题的好处），为什么还要麻烦呢？

  • 我想要一组“英语”规则来描述从底层原始数据到应用程序（网络）可以直接使用的表单的转换

似乎您在谈论一个经典的持久层，上面有一个服务层。您的服务层中的"english-language" rules方法"english-language" 在哪里。除非您需要更复杂的规则引擎，但大多数时候它是不需要的。

于 2011-09-26T01:07:03.963 回答
1

为什么要摆脱关系方法？通过从关系方法转移，您只会通过使用任何其他方法将业务逻辑更深地埋入代码中。正如您所指出的，数据模型相当简单。您可以首先考虑改进数据模型本身。它们可能不是任何参照完整性约束的原因是因为最初的设计者可能认为这会导致性能下降。他们可能正在使用本身可能效率低下的代码进行检查。

你的数据库很小。添加参照完整性约束不会以任何方式影响性能。如果需要，您可以重写一些 UDF。为什么不使用查询分析器来查看性能指标？这将为您提供一个很好的分析起点。

于 2010-01-29T06:52:51.630 回答