如何构造多个和/或复杂的SQL查询？

Question

有了相当多的SQL查询，其中很多是临时查询，数据库变得有点混乱。我有两个问题：

1. 很难保持许多不同的视图/sproc的良好秩序，而只使用名称来构造它们
2. 子查询(在2-4级别调用其他视图的视图)增加了结构混乱，很难维护。

现在，我希望在我的数据库和/或C#代码中获得一个更好的结构(可以是java/python/ruby/任何东西)。多么?

我应该使用SQL中的“架构”来分隔不同领域的视图吗？就像名字空间。

我是否应该避免在数据库中使用大量的TSQL，而应该继续查询我的C#？这将使数据库逻辑更接近系统的其他部分，并且更容易维护和保持代码版本控制，但同时我也很喜欢接近数据，以保持良好的性能(借助SQL分析器的帮助)。

还有其他建议吗？

更新:数据库和c#-项目已经有了几年的历史，并且已经增长，并将继续增长(功能的不同领域)+新的项目将被添加。我需要用一种好的方式把它清理干净，或者改变策略。

Answer 1

Ok，为什么C#代码中的复杂性比TSQL中的复杂性更容易管理？

这必须是，您的工具或C#的知识是优越的。你应该解决这个问题。

您可以采用命名约定，并组织文件以帮助完成此任务。使用开发环境支持TSQL和源代码管理。确保可以以编程方式部署新的和升级的数据库架构。就像你应该和C#一样。

如果不知道项目的细节，我就无法指定确切的结构。

您应该如何决定在哪里实现逻辑？

在一般情况下，这很简单。

数据库应该执行基于集合的操作，这些操作可以从对数据使用indecies中受益。这段代码更容易用TSQL和其他基于集合的查询语言编写。

应用程序/业务层应该执行行级操作，最好是以无状态(Shared/static)的方式执行。这段代码更容易用c#和其他过程语言编写。

与无状态应用程序层相比，扩展数据库服务器更困难。如何维护多台计算机之间的同步？

没有完全正确的答案。只有许多灰色的阴影。最好的解决方案将基于您的需求。从MS事实上的VS 2013，SQL 2012，C#，EF6和修饰或简化开始。

Answer 2

我刚刚找到了Martin "Domain“http://martinfowler.com/articles/dblogic.html的这篇文章。

先表演？

“人们首先考虑的问题之一是性能。就我个人而言，我认为性能不应该是第一个问题。我的哲学是，大多数时候你应该集中精力编写可维护的代码。然后使用分析器来识别热点，然后用更快但不太清晰的代码替换那些热点。”

维修性

“对于任何长期存在的企业应用程序，您都可以确定一件事--它将发生很大的变化。因此，您必须确保系统的组织方式易于更改。可修改性可能是人们将业务逻辑放入内存=应用程序代码而不是TSQL中的主要原因。”

封装

“使用视图，或者实际上是存储过程，只能在一定程度上提供封装。在许多企业应用程序中，数据来自多个源，不仅来自多个关系数据库，还来自遗留系统、其他应用程序和文件。在这种情况下，完全封装实际上只能由应用程序代码中的一个层完成，这进一步意味着域逻辑也应该位于内存中。”