既然你没有说明数据库的目的或要求,这里有一些一般的东西,没有特别的顺序:
- 每个表上的小型聚簇索引。考虑将此作为每个表的主键。这将非常有效并节省主表和从属表中的空间。
- 适当的非聚集索引(尽可能覆盖索引)
- 参考诚信
- 规范化表格
- 在所有数据库对象上进行一致命名以便于维护
- 如果您拥有SQL Server企业版
,则进行适当的分区(表和索引)
- 如果要允许在数据库中进行直接数据操作,则对表进行适当的检查约束。
- 决定您的业务规则将驻留在哪里,并且不要偏离。在大多数情况下,它们不属于数据库。
- 对您频繁使用的查询运行查询分析器(至少)并查找表扫描。这会扼杀性能。
- 准备好应对僵局。使用这种大小的数据库,特别是如果会有大量写入,死锁很可能是一个问题。
- 充分利用视图来隐藏查询连接的复杂性以及查询优化和灵活安全实现的潜力。
- 考虑使用模式来更好地组织数据和灵活的安全实现。
- 熟悉Profiler。使用这种大小的数据库,您很可能会花一些时间来确定查询瓶颈。 Profiler可以在这里为您提供帮助。
醇>
根据经验,如果一个表包含超过2500万条记录,则应考虑表(和索引)分区,但此功能仅适用于SQL Server企业版(相应地,开发人员版)。