开发新的SQL数据库时常见的缺陷是什么？

Question

我知道，我完全不喜欢这个包罗万象的调查类型问题，但我想不出更好的方法来找出我认为我需要知道的内容。我在数据库开发领域非常环保，只处理过少量只与数据库交互的项目，而不是从头开始实际创建一个新项目。然而，事情发生了变化，现在我面临着创建自己的数据库的问题。

到目前为止，我已经创建了我需要的表，并添加了我认为我需要的列，包括用于多对多关系的任何链接表以及用于一对多关系的列。我对此有一些具体的问题，但我觉得不应该只是回答这些问题，而是询问我可能甚至不知道的事情会更有意义，我现在应该解决这个问题，而不是从现在开始工作6个月后使用它的数据库和客户端工具。

首先我的数据库上的问题让我意识到我不够了解：

1. 当对引用的表进行更改时，如何确保我的多对多链接表和我的一对多列是最新的？我可能遇到什么问题？
   • 我对各种文本字段使用nvarchar（n）和nvarchar（MAX）。我应该使用varchar等价物（我读过使用nvarchar可能存在性能风险）？除了担心使用固定长度的char数组来保存可变长度信息之外，还有其他关于数据类型选择的问题吗？有关如何选择适当数据类型的任何规则？
   • 我使用int作为每个表的ID列，这是除了链接表之外的所有链中的主键（我有两个主键，ID的引用的表行）。此ID设置为标识。这种方法有缺陷吗？
   • 我已经为单元类型和状态等内容创建了元数据表，但我不知道这是否正确。你应该为枚举列表之类的东西创建新表还是有更好的方法？

我知道数据库是复杂的，并且是许多有价值的主题的主题，但我怀疑你们中的许多人都有一些提示和技巧来增加这些阅读材料（虽然也欢迎基本阅读提示）。

由于这类帖子相当主观，所以社区维基。如果这是重复的道歉，我已经对这样的事情进行了一些搜索，但找不到任何搜索，尽管this one is certainly related。感谢。

更新

我刚刚找到this question，这在迂回的方式非常相似。

Answer 1

1. 未正常化
2. 未使用标准化
3. 尝试从头开始实现非规范化架构

严重：

1. 外键将禁止从父表中删除或更新。或者它们可以级​​联。

2. 尽可能小：2个最近的SO问题datatypes和(n)varchar

3. 可能无法移植，您的“自然密钥”（比如“产品名称”）仍然需要一个唯一约束。否则不行，但请记住，IDENTITY列是“surrogate key”

编辑：假设您希望使用FruitID和FruitName列存储水果。您无法限制“Apple”或“Orange”的出现，因为虽然这是您的“自然键”，但您使用的是代理键（FruitID）。因此，为了保持完整性，您需要对FruitName

具有唯一约束
1. 不确定或你的意思，对不起。编辑：不要这样做。 Ye olde“One true lookup table”的想法。

Answer 2

我会用一些模糊的一般性来回答你的主观质疑。 ：）

设计数据库最常见的陷阱是任何编程解决方案都存在同样的缺陷，而不是完全理解正在解决的问题。对于数据库，它理解数据的性质。它有多大，它来来去去，它必须遵守什么样的商业规则。

以下是一些值得思考的问题。

最常更新的内容是什么？保持该表写入锁定会锁定查询吗？它会成为热点吗？如果你不理解你的读写比率，即使看似很好的规范化模式也可能表现不佳。

您的外部接口需要什么？我一直在进行项目，其中“其他系统”的虚线几乎破坏了整个项目，因为实施它被推迟到其他一切都到位，也就是说，其他一切都不灵活。

还有其他未说出口的要求吗？我最喜欢的是日期敏感度。所有的数据都在那里，你的报告很漂亮，老板看着他们，并询问，这个数据什么时候改变了？是谁做的，什么时候做的？数据库是应该跟踪自己及其用户，还是只跟踪数据？你的前端会为你做这件事吗？

只需要考虑一些事情。

Answer 3

听起来你很清楚自己的目标是什么，而且确实没有“一条真正的道路”去做数据库。

您是否为层次结构对象设置了级联（即，数据库中对象“头部”的单个删除将删除与该条目相关的表中的所有条目）？

您的链接表和1：n列应该是外键，因此没有太多担心数据是否会发生变化。这里用“两个主键”，你的意思是索引吗？

至于元数据表，过去我已经完成了它们，我还没有完成它们。具有SQL注释的单个字符状态可以满足一组有限的状态，但超出一定量，或者您可以考虑在将来添加更多状态，您可能希望引用另一个元数据表，或者可能是炭（8ish）。例如，我看到用户表的用户类型有“NORMAL”，“ADMIN”，“SUPER”，“GUEST”等，这可能是“UserType”表中的1,2,3,4,5个fkeys ，但是如此有限的枚举是否重要？其他人有一张权限表（用户可以做的布尔值） - 很多方法可以给猫皮肤。

Answer 4

您可能会在这些幻灯片中找到一些可用的内容： [http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back][1]

Answer 5

我也是数据库设计的初学者，但我发现这个在线教程非常非常有用：

Database design with UML and SQL, 3rd edition

作者以非常清晰的方式解释了数据库的所有基本设计方面。在我找到这个在线指南之前，我做了很多关于规范化的维基百科阅读。虽然这有所帮助，但是作者解释了完全相同的东西（通过第三范式，至少），但是以更容易阅读的方式。它几乎解决了你的所有问题。

Answer 6

我建议一本好书。最好的IMO是：

http://www.amazon.com/Server-2005-Database-Design-Optimization/dp/1590595297/ref=ntt_at_ep_dpt_1

Answer 7

除了没有规范化之外，我看到的一个常见问题是过度索引，在进行性能测量之前已经完成，并考虑了生产中的读取与写入组合。

添加索引以加快查询速度真的非常容易，当你有多个在INSERT或UPDATE期间得到更新时，更难以找出要删除的索引。

中间地带是明显的二级索引（例如，对于大型表上的名称进行常见，频繁的查找），推迟其他候选索引，直到您进行了合理的性能测试。

Answer 8

除其他外，不使用主键，没有考虑你是否将使用索引视图（并相应地设计表;我曾经不得不删除并在我的站点重新创建一个大表以将其ANSI_NULL属性更改为ON这样我就可以使用索引来使用它了。