相关疑难解决方法(0)

我从小就受过教育——在那里我们学会了在应用程序的业务层之前设计数据库模式（或将 OOAD 用于其他一切）。我一直很擅长设计模式（恕我直言:) 并且规范化只是为了删除不必要的冗余，而不是影响速度的地方，即如果连接是性能下降，冗余就留在原地。但大多数情况并非如此。

随着一些 ORM 框架的出现，如 Ruby 的 ActiveRecord 或 ActiveJDBC（以及其他一些我不记得了，但我相信有很多）似乎他们更喜欢为每个表设置一个代理键，即使有些有主键，例如'email' - 彻底打破 2NF。好吧，我不太明白，但是当这些 ORM（或程序员）中的一些不承认 1-1 或 1-0|1（即 1 比 0 或 1）时，我（几乎）会感到紧张。他们规定，无论是否有大量nulls “今天的系统可以处理它”，最好将所有东西都放在一张大桌子上，这是我经常听到的评论。

我同意内存限制确实与规范化直接相关（还有其他好处:)但是在今天内存便宜和四核机器的时代，数据库规范化的概念是否只是留给文本？作为 DBA，您是否仍然练习标准化为 3NF（如果不是 BCNF :)？有关系吗？“脏模式”设计对生产系统有好处吗？如果它仍然相关，那么应该如何将其“用于”规范化。

（注意：我不是在谈论数据仓库的星形/雪花模式，它们具有冗余作为设计的一部分/需要，而是具有后端数据库（例如 StackExchange）的商业系统）

我们公司目前为每个 SQL Server 2005 实例托管大约 400 个数据库。500-600 个数据库，我们看到性能开始下降。数据库大小在极端情况下从 50mb 到 40-60gb 不等，平均可能只有几 GB。

有哪些好的指标需要收集，我们如何获取这些指标来确定我们的瓶颈？

SQL Server 数据库太多是不是性能限制？是数百个数据库的数百个存储过程的所有缓存过程计划吗？查询效率低吗？还是组合？

什么最有可能帮助我们增加每台服务器的数据库数量？所有模式都是相同的，并且数据库将每个客户的数据分开。也许重构一切以便我们可以将多个客户合并到一个数据库中并按客户过滤，或者将我们的查询优化到极致？或者它可能只是 SQL Server 的限制？

我知道在向大表中添加新字段时，建议将它们添加到字段的末尾而不是中间的某个位置，并且想知道在更改字段类型时是否适用这样的事情？

我有一个包含大约一百万条记录的表，其中包含几个 VARCHAR 类型的字段。我想将这些更改为 NVARCHAR，但据我所知，这将需要一些时间和资源，因为字段位于表的中间，并且 SQL Server 必须进行大量复制/重新排序。

实现这一目标的有效方法是什么？