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