我已经开始从事金融服务行业的项目，该项目主要基于SQL Server（2000），ColdFusion（8）和一些Access / .NET应用程序。该项目以一些简单的Access表单/ VBA开始，并慢慢转换为Web界面。
我可以说数据库设计和应用程序编码是由那些在工作中学习并且没有机会从一开始就了解好的设计原则的人完成的。许多业务规则都设置在无数级联功能和存储过程以及Web服务器模板中。在使用未注释常量的复杂500行SQL UDF中，存在大量特殊情况处理。跟踪可能涉及查询的10-20个UDF之间的所有交互非常困难。一些查询似乎花了太长时间才能运行（最多15分钟）。
虽然表格索引相当好，但缺乏FK关系，几乎没有参照完整性。数据库不经常更新，每日批量低（多个表中有1,000条记录）。它主要用作数据存储库 - 我想是一个数据仓库。我们遇到非常罕见的死锁或延迟。
所以，我的问题是：如果我想重新实现包括数据库和前端在内的整个项目，那么查看非关系实现是否有意义？主DB只有大约1GB（.mdf），因此它可以很容易地放在内存中。我想从SQL查询结构转移到一些可以有效编译和执行的声明性模型。如有必要，我可以将SQL DB用作数据存储。
答案 0 :(得分：1)
为什么要转向关系方法？通过从关系方法转移，您只能通过使用任何其他方法将业务逻辑深入到代码中。正如您所指出的，数据模型非常简单。您可以先看看改进数据模型本身。它们可能不是任何参照完整性约束的原因是因为初始设计者可能认为这会导致性能降低。他们可能正在使用本身效率低下的代码进行检查。
您的数据库很小。添加参照完整性约束不会以任何方式影响性能。如果需要，您可以重写一些UDF。为什么不使用查询分析器来查看性能指标？这将为您提供一个良好的分析起点。
答案 1 :(得分：1)
一般来说，大多数开发人员，甚至那些呼吸map / reduce，穿NoSQL T恤的人，对SQL感觉更舒服。
如果您的应用程序遵循经典的MVC / MVP模型，那么大多数框架（例如Spring，Rails，Grails，Django，Webmachine等）实际上都带有第一类支持SQL后端。并且对NoSQL的一些支持。
如果您发现NoSQL无法为您的系统带来任何实际好处（here是我发布给另一个问题的好处），为什么还要烦恼？
似乎您在谈论一个经典的持久层，其上面有一个服务层。服务层中"english-language" rules只是"english-language" 方法的位置。除非您需要更复杂的规则引擎，否则大部分时间都不需要它。