有相当多的 SQL 查询，其中许多是临时查询，数据库变得有点混乱。我有两个问题：
现在我想在我的数据库和/或我的 C# 代码（可以是 java/python/ruby/whatever）中获得更好的结构。如何？
我应该在 SQL 中使用“模式”来分隔不同区域的视图吗？就像命名空间一样。
我是否应该避免在数据库中包含大量 TSQL，而是将查询保留在我的 C# 中？这将使数据库逻辑更接近系统的其余部分，并且更容易维护和保持代码版本控制，但同时我很欣赏接近数据，以保持良好的性能（在 SQL 的帮助下探查器）。
还有什么建议吗？
更新：数据库和 c#-projects 已经有几年历史了，并且已经增长，并且会随着时间的推移继续增长（不同的功能领域）+ 将添加新项目。我需要以一种好的方式清理它，或者改变策略。
我刚刚发现 Martin Fowler 的这篇文章“域逻辑和 SQL” http://martinfowler.com/articles/dblogic.html。
性能第一？
“人们对这类事情首先考虑的问题之一是性能。我个人认为性能不应该是第一个问题。我的理念是，大多数时候你应该专注于编写可维护的代码。然后使用分析器来识别热点，然后只用更快但不太清晰的代码替换那些热点”
可维护性
“对于任何长期存在的企业应用程序，您可以确定一件事 - 它会发生很大变化。因此，您必须确保系统以易于更改的方式组织。可修改性可能是主要的人们将业务逻辑放在内存中的原因 [= 应用程序代码而不是 TSQL]。”
封装
“使用视图，或者实际上是存储过程，只能在一定程度上提供封装。在许多企业应用程序中，数据来自多个来源，不仅仅是多个关系数据库，还包括遗留系统、其他应用程序和文件。[...]这种情况下，完全封装实际上只能由应用程序代码中的一层来完成，这进一步意味着域逻辑也应该位于内存中。”
好的，为什么 C# 代码中的复杂性比 TSQL 中的复杂性更容易管理？
一定是您的 C# 工具或知识更胜一筹。你应该解决这个问题。
您可以采用命名约定并组织文件以帮助完成此任务。使用开发环境来支持 TSQL 和源代码控制。确保您可以以编程方式部署新的和升级的数据库模式。就像你应该使用 C# 一样。
在不知道您项目的详细信息的情况下，我无法指定确切的结构。
你应该如何决定应该在哪里实现逻辑？
在一般层面上，这很简单。
数据库应该执行基于集合的操作，这些操作可以从对您的数据使用不规范中受益。这段代码更容易用 TSQL 和其他基于集合的查询语言编写。
您的应用程序/业务层应该执行行级操作，理想情况下以无状态 ( Shared/ static) 方式。这段代码更容易用 c# 和其他过程语言编写。
扩展数据库服务器比无状态应用层更难。您如何保持多台机器之间的同步？
没有确切的正确答案。只有许多灰色阴影。最佳解决方案将基于您的要求。从 MS Defacto VS 2013、SQL 2012、C#、EF6 开始，然后从那里进行修饰或简化。