使用 SQL Server 还是 C# 进行数据库设计？
数据库应该在 SQL Server 还是 C# 上设计？
我一直认为在 SQL Server 上设计它更合适，但最近我开始阅读一本书（Pro ASP.NET MVC Framework），据我了解，这本书基本上说用 C# 编写它可能是一个更好的主意，因为你将通过 C# 访问模型，这确实有意义。
我想知道其他人对此事的看法是什么......
我的意思是，例如，您是否认为“正确”有一个指定常量的表（例如总是应该包含的 AccessLevel 表）
每个人 1 人2 名开发人员3 管理员4 名主管5 受限
如果仅仅使用一个枚举来达到同样的目的，不是会更加健壮和简化吗？
Should a database be designed on SQL Server or C#?
I always thought it was more appropriate to design it on SQL Server, but recently I started reading a book (Pro ASP.NET MVC Framework) which, to my understanding, basically says that it's probably a better idea to write it in C# since you will be accessing the model through C#, which does make sense.
I was wondering what everyone else's opinion on this matter was...
I mean, for example, do you consider "correct" having a table that specifies constants (like an AccessLevel table that is always supposed to contain
1 Everyone2 Developers3 Administrators4 Supervisors5 Restricted
Wouldn't it be more robust and streamlined to just have an enum for that same purpose?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
数据库模式应在纸上或使用 ERD 工具设计。
它应该在数据库中实现。
您是否正在考虑 ORM 像 实体框架 允许您使用代码生成数据库？
就我个人而言，我宁愿在纸上仔细考虑我的设计，然后再将其提交给数据库。我很乐意稍后使用此数据库中的 ORM 或类生成器。
A database schema should be designed on paper or with an ERD tool.
It should be implemented in the database.
Are you thinking about ORMs like Entity Framework that let you use code to generate the database?
Personally, I would rather think through my design on paper before committing it to a DB myself. I would be happy to use an ORM or class generator from this DB later on.
在 VS.NET 2010 之前，我使用 SQL Server Management Studio 来设计数据库，现在我使用 EF 4.0 设计器，对我来说这是最好的方法。
Before VS.NET 2010 I was using SQL Server Management Studio to design my databases, now I am using EF 4.0 designer, for me it's the best way to go.
如果您的问题域很复杂或者其复杂性随着系统的发展而增加，您很快就会发现您需要一些元数据来让生活变得更轻松。 C# 作为此类内容的宿主语言是一个不错的选择，因为您可以利用其类型系统来强制执行一些不变量（例如字符列长度、空/非空限制或检查约束；您可以将其声明为 const、枚举） ， ETC）。不幸的是，我不知道可以开箱即用的实用程序（sqlmetal.exe 可以导出一些元，但只能导出为 xml），尽管某些 CASE 工具可能可以自定义。我会使用一些定制的生成器来从 C# 生成数据库模式（与学习相比，例如 Sybase PowerDesigner 提供的定制选项，只需几个小时）。
If your problem domain is complex or its complexity grows as the system evolves you'll soon discover you need some meta data to make life easier. C# can be a good choice as a host language for such stuff as you can utilize its type-system to enforce some invariants (like char-columns length, null/not null restrictions or check-constraints; you can declared it as consts, enums, etc). Unfortunately i don't know utilities (sqlmetal.exe can export some meta but only as xml) that can do it out of the box, although some CASE tools probably can be customized. I'd go for some custom-made generator to produce the db schema from C# (just a few hours work comparing to learning, for example, customization options offered by Sybase PowerDesigner).
ORM 有其用武之地，但那个地方不是数据库设计。设计数据库时需要考虑很多因素，但这些因素不会自动生成，无论不考虑设计的想法多么吸引人。通常需要考虑许多与应用程序无关的事情，例如数据完整性、报告、审计表和数据导入。使用 ORM 创建看起来像对象模型的数据库可能不是最佳的性能设计，并且可能不具备您在数据完整性方面真正需要的东西。请记住，即使您认为除了应用程序之外没有任何东西会接触数据库，但事实并非如此。在某些时候，数据库需要有人直接在数据库上而不是通过应用程序进行主要的数据修订（以解决问题）。在某些时候，您将需要从您刚刚购买的其他公司导入一百万条记录，并且需要在应用程序之外进行 ETL 流程。将所有希望和梦想寄托在数据库（以及数据完整性规则）上是短视的。
ORMs have their place, that place is NOT database design. There are many considerations in designing a database that need to be thought through not automatically generated no matter how appealing the idea of not thinking about design might be. There are often many things that need to be considered that have nothing to do with the application, things like data integrity, reporting, audit tables and data imports. Using an ORM to create a database that looks like an object model may not be the best design for performance and may not have the the things you really need in terms of data integrity. Remember even if you think nothing except the application will touch the database ever, this is not true. At some point the data base will need to have someone do a major data revision (to fix a problem) that is done directly on the database not through the application. At somepoint you are going to need need to import a million records from some other company you just bought and are goping to need an ETL process outside teh application. Putting all your hopes and dreams for the database (as well as your data integrity rules) is short-sighted.