在创建数据库结构时,有哪些好的指导原则或好的方法来确定数据库应该规范化到什么程度?您是否应该创建一个非规范化数据库,并在项目进行过程中将其拆分?您是否应该创建完全标准化的表,并根据性能需要组合表?
发布于 2008-09-06 18:48:41
你想要开始设计一个规范化的数据库,直到第三范式。当你开发业务逻辑层时,你可能会决定你必须进行一些非规范化,但绝不会,永远不会低于第三种形式。始终保持第一种和第二种形式的兼容性。您想要反规范化是为了简化代码,而不是为了提高性能。为此使用索引和存储过程:)
不是“随时随地规范化”的原因是,每次修改数据库设计时,您都必须修改已经编写的代码。
有几篇很好的文章:
http://www.agiledata.org/essays/dataNormalization.html
发布于 2008-09-06 19:05:42
@GrizzlyGuru一个智者曾经告诉我“正常化直到它伤害,去正规化直到它起作用”。
它还没有让我失望:)
我不同意以非规范化的形式开始,然而,根据我的经验,调整你的应用程序来处理一个不太规范化的数据库比一个更规范化的数据库更容易。它还可能导致这样的情况:它“工作得足够好”,所以你永远不会去标准化它(直到“为时已晚”!)
发布于 2008-09-17 12:59:23
标准化意味着消除冗余数据。换句话说,非规范化或非规范化数据库是一个数据库,其中相同的信息将在多个不同的地方重复。这意味着您必须编写更复杂的update语句,以确保您在任何地方都更新相同的数据,否则会得到不一致的数据,这反过来意味着查询的输出是不可靠的。
这是一个相当大的问题,所以我会说反规范化是有害的,而不是相反。
在某些情况下,如果您判断这样做的好处超过了更新数据的额外工作和数据损坏的风险,那么您可能会故意决定对数据库的特定部分进行反规范化。例如,对于数据仓库,由于性能原因,数据被聚合,并且数据通常在初始条目之后不更新,这降低了不一致的风险。
但总的来说,你已经厌倦了为了性能而去规格化。例如,非规范化连接的性能优势通常可以通过使用物化视图(也称为索引视图)来实现,这将与查询非规范化表一样快,但仍然可以保护数据的一致性。
https://stackoverflow.com/questions/47711
复制相似问题