Questions tagged «normalization»

我正在与我工作的公司的开发人员进行永久性讨论，因为他们说最好摆脱关系数据库中的关系强制（通过FOREIGN KEY约束定义），以便加快大型查询并获得更好的结果。性能。 所考虑的平台是MySQL 5.x，并且尚未设置FOREIGN KEY，甚至缺少相关表的一些PRIMARY KEY约束，至少对于我来说，这是不合理的。也许他们是对的，但我是错的，但我没有足够的论点来讨论这种情况。 三年来，这一直是首选方法。我是这家公司的新手（只有一个月），但是随着产品的“上市”，人们在犹豫是否要增强数据库。话说回来，我注意到的第一件事是一页需要1分钟的加载时间（是的，需要60秒！）。 当前事务状态背后的一种说法是，“非规范化”数据库比规范化数据库要快，但我认为那不是真的。 大多数相关查询都包含JOIN操作，这使它们在处理大量数据（数据库包含数百万行）时非常非常非常慢地运行。 通常，“ CRUD”操作的处理是在应用程序代码级别实现的；例如，为了删除一些数据自，例如TableA： 必须首先即时检查TableA和的行之间是否存在某种关系TableB， 如果上述关系被“检测到”，则应用程序代码将不允许删除相关行，但是 如果由于某种原因该应用程序代码失败，则无论涉及的行和表是否存在任何关系，DELETE操作都将“成功”进行。 题 您能帮我拟定一个良好，准确而可靠的答案以丰富辩论的内容吗？ 注意：也许以前有人问过（并回答过）类似的问题，但是我无法通过Google找到任何东西。

10 mysql  database-design  normalization  relational-theory  denormalization 

我偶然发现了一个数据库设计问题，而这个数据库设计问题超出了我的能力范围，而我的DBA专家也开始进行防火训练。 本质上，我有一个带有以下主键的表（为简洁起见，PK）： child_id integer parent_id integer date datetime child_id并且parent_id是实体表的外键。“子”表本身还包含“父”表的外键，并且lo child_id始终引用与parent_id上表所期望的相同的外键。实际上，事实证明，还有一些额外的代码可以使两者保持同步。 这使这位热情洋溢的标准化新手说：“我应该删除冗余！” 我分解为以下内容： Table_1 PK: child_id integer date datetime Table_2 PK: parent_id integer date datetime Table_3: (already exists) child_id integer PRIMARY KEY parent_id integer FOREIGN KEY 而且，当我自然地将这些人加入一起时，我将恢复原始表。据我了解，制造出了5NF。 但是，现在我意识到存在隐藏的业务规则。 通常，与给定日期关联的日期child_id必须是与对应日期关联的日期的子集parent_id。您可以看到第一个表强制执行此规则。 我的分解不会强制执行该规则，因为您可以自由地将其添加到表1中，直到日期变得太大为止。 这将我引向以下问题： 这是5NF分解吗？虽然我说它允许插入异常，但它似乎也遵循Wiki示例，该示例本身遵循本指南。短语（强调我）“我们可以从由三种不同的记录类型组成的规范化形式中重构所有真实事实”，这给了我一个特殊的停顿，因为无论我注入多少垃圾Table_1，自然连接仍然会忽略它。 假设我不喜欢这种分解（我不喜欢）。我自由地承认，实际的解决方案是保留表和代码不变。但是，从理论上讲，是否有一种方法可以分解和/或添加约束，以使我摆脱第一个表并保留我的业务规则？

10 database-design  schema  normalization  relational-theory  best-practices 

我正在制作一个小程序，用户可以在其中编写帖子或撰写博客。在这些帖子上，其他用户可以像在Facebook中那样喜欢或不喜欢该帖子，或者像在stackoverflow中那样对帖子进行赞或不赞成。我想知道一个常用的良好数据库结构，并且该程序可以有效地使用该结构。我有两个选择 第一 发布： id head message datepost likes dislikes 1 ab anchdg DATE 1,2,3 7,55,44,3 以上述方式，id是postid。在“喜欢”列中，1,2,3是喜欢或赞成该帖子或博客的用户的ID。7,55,44,3是不喜欢或不赞成该帖子或博客的用户的ID。 第二 发布： id head message datepost 1 ab anchdg DATE 喜欢： id postid userid 1 1 1 2 2 2 不喜欢： id postid userid 1 1 7 2 1 55 这样，我必须为喜欢和不喜欢创建两个单独的表，以获取帖子的喜欢。这样，表即Likes＆Dislikes将被大量填充。这可能会使表沉重，处理速度变慢。 因此，我想知道哪种更好和更标准的方法来完成此任务？

10 mysql  database-design  normalization  string 

在一次演讲中，我的讲师向我们展示了一个没有主键的桌子。在询问时，他说在3NF中，当您删除传递依赖项时，可以有一个没有主键的表。 但是，没有主键意味着没有功能依赖关系-但是3NF消除了传递依赖关系，并且我被告知每个表都需要有一个用于规范化的主键，因为它全都与功能依赖关系有关。 我知道完全可以创建没有主键的表，但是如果该表存在，该数据库是否被视为规范化的？ 我应该补充一点，该表没有任何“唯一键”，没有主键，没有复合键，没有外键。 所显示的表具有三个属性，没有一个被标记为主要或唯一。我问这是否是一个错误，他说没有一个是很好。我质疑此评论，因为表中的任何信息都无法唯一标识，他声称可以这样。这违背了我关于标准化的知识。

9 database-design  normalization  relational-theory 

我试图得到什么是第一范式的确定版本。我阅读的所有内容都有一个稍微不同的旋转。 许多机构（例如Date）说，根据定义，关系始终是“第一范式”，而其他机构则列出了要求列表。这意味着对1NF的需求从零到很多。 我猜想区别在于表和关系之间的关系：表可能是一个完整的混乱，而关系则受到某些限制。关系在SQL中表示为表的事实因此造成了一些混乱。 我特别关注与SQL数据库有关的1NF。问题是：要确保表格采用第一范式需要哪些属性？ 许多权威人士建议，如果表表示一个关系，则该表已经存在于1NF中。这将1NF的定义推回到关系的定义。 以下是1NF中表格的一些属性： 列顺序微不足道[1] 行顺序微不足道 所有行的长度相同（即，行数据与列标题匹配） 没有重复的行（可以使用代理主键来保证，但是PK本身不是必需的） 没有重复的列 每一列包含一个单一值（原子） [1]从技术上讲，属性是无序的，但是在表中，行数据的顺序必须与列标题的顺序相同。但是，实际顺序并不重要。 在多个数据上： 原子数据的概念是不能进一步分解项目。此概念已经过资格验证，尽管从技术上讲，所有内容都可以细分为恶心，但实际上，取决于所使用的数据的方式，所讨论的数据无法进一步细分。 例如，完整的地址或全名通常应进一步细分，但是诸如给定名称或城镇名称之类的组件可能不应进一步细分，尽管事实上它们可以是字符串。 至于重复的列，它是一个设计不良列具有近重复列，例如phone1，phone2等。通常，重复数据指示用于一个附加的相关表的需要。 依存关系 行之间不应有任何关系，除非它们符合相同的标题。 列之间也应该没有关系，但是我认为这是较高范式的主题。 问题是：上面的多少在1NF的定义中？独立行位也进入其中吗？

9 database-design  normalization  relational-theory 

假设我有一个名为的表User_FriendList，它具有以下特征： CREATE TABLE User_FriendList ( ID ..., User_ID..., FriendList_IDs..., CONSTRAINT User_Friendlist_PK PRIMARY KEY (ID) ); 让我们假设该表包含以下数据： + ---- + --------- + --------------------------- + | ID | 用户名 | Friendlist_IDs | + ---- + --------- + --------------------------- + | 1 | 102 | 2：15：66：35：26：17：| + ---- + --------- + --------------------------- + …

9 database-design  foreign-key  normalization  relational-theory 

有人可以简单地给我解释一下overlapping candidate key吗？overlapping顾名思义，这是什么意思？ 考虑以下关系 R(L,M,N,O,P) { M -> O NO -> P P -> L L -> MN } 上面的哪个功能依赖性在上面的关系中带来了重叠的候选键？ 让我们将讨论范围限制为依赖项，目前我对BCNF不感兴趣

8 database-design  normalization  dependencies 

我正在为以下情况创建数据库方案： 有用户 用户具有角色（例如“开发人员”或“ CEO”） 角色具有应用程序（例如“ Topdesk”） 应用程序具有权限（例如“更新知识库”） 如果角色已经可以访问应用程序，则该角色可以具有权限 假设没有高性能环境（无需针对速度进行优化），那么实现此架构的最佳方法是什么？数据库环境可以是MySQL，MSSQL ...更多是关于关系数据库的设计。 我本人提出以下建议： 我最不确定的部分当然是Applications_Permissions_Roles表。它是另一个链接表之上的链接表。我以前从未使用过或看过。做到这一点的另一种方法是将其替换为“角色”和“权限”之间的链接表，然后使用代码或约束来确保所需的关系...但这对我来说似乎不是一个好的解决方案。这些事情应该在数据库级别（如果可能）上强制执行，而不是在代码级别上强制执行。 其次，是否需要Permissions.Application和Applications.Id之间的链接？我之所以使用它，是因为Roles_Applications中可能没有任何行（例如，当您刚刚添加了新应用程序时），因此无法确定哪些权限属于哪个应用程序。它也是查阅权限所属于的应用程序的单一参考点。我想这是对的，但它在数据库设计中也有影响。尝试将ON_DELETE或ON_UPDATE设置为级联时，会出现MSSQL错误。 有什么建议，或者这是应该怎么做的？也欢迎任何其他有关命名约定的建议（例如作为评论）。 谢谢， 卢克 编辑：更改标题，希望使其更清晰。前一个比较全面，但可能太复杂了。

8 database-design  normalization  relational-theory 

我是创建数据库的新手...我需要为我的招聘Web应用程序创建数据库。 我的应用程序需要安排申请人的筛选，考试和面试，并将结果保存在数据库中。 我的数据库架构如下： 我的问题是我applicant_id在其他表格中包括...，例如考试，面试，考试类型。 我违反任何规范化规则吗？如果这样做，您建议如何改进我的设计？

8 normalization  database-design