应该在 SQL Server 还是 C# 上设计数据库？
我一直认为在 SQL Server 上设计它更合适，但最近我开始阅读一本书（Pro ASP.NET MVC Framework），据我了解，它基本上说写它可能是一个更好的主意C#，因为您将通过 C# 访问模型，这很有意义。
我想知道其他人对这件事的看法......
我的意思是，例如，您是否认为拥有一个指定常量的表是“正确的”（例如始终应该包含的 AccessLevel 表）
1 Everyone2 Developers3 Administrators4 Supervisors5 Restricted
为了同样的目的只使用一个枚举不是更健壮和精简吗？
【问题讨论】：
标签： c# sql-server linq-to-sql database-design
应在纸上或使用ERD 工具设计数据库架构。
应该在数据库中实现。
您是否正在考虑使用 ORMs 之类的 Entity Framework 让您使用代码生成数据库？
就我个人而言，我宁愿在自己将其提交给数据库之前在纸上仔细考虑我的设计。稍后我会很乐意使用此数据库中的 ORM 或类生成器。
【讨论】：
在 VS.NET 2010 之前，我使用 SQL Server Management Studio 来设计我的数据库，现在我使用 EF 4.0 设计器，对我来说这是最好的方式。
【讨论】：
如果您的问题域很复杂，或者随着系统的发展而变得复杂，您很快就会发现您需要一些元数据来让生活更轻松。 C# 作为宿主语言是一个不错的选择，因为您可以利用它的类型系统来强制执行一些不变量（如字符列长度、null/not null 限制或检查约束；您可以将其声明为 consts、枚举， 等等）。不幸的是，我不知道可以开箱即用的实用程序（sqlmetal.exe 可以导出一些元数据，但只能导出为 xml），尽管一些 CASE 工具可能可以自定义。我会使用一些定制的生成器从 C# 生成 db 模式（与学习相比只需几个小时，例如 Sybase PowerDesigner 提供的自定义选项）。
【讨论】：
ORM 有它的位置，那个位置不是数据库设计。在设计数据库时需要考虑许多注意事项，而不是自动生成，无论不考虑设计的想法多么吸引人。通常需要考虑许多与应用程序无关的事情，例如数据完整性、报告、审计表和数据导入。使用 ORM 创建看起来像对象模型的数据库可能不是性能的最佳设计，并且在数据完整性方面可能没有您真正需要的东西。请记住，即使您认为除了应用程序之外什么都不会触及数据库，这是不正确的。在某些时候，数据库将需要有人直接在数据库上而不是通过应用程序进行主要的数据修订（以解决问题）。在某些时候，您将需要从您刚购买的其他公司导入一百万条记录，并且需要在应用程序之外进行 ETL 流程。把你所有的希望和梦想都寄托在数据库上（以及你的数据完整性规则）是短视的。
【讨论】：