【问题标题】:DB Schema design, table with many columnsDB Schema 设计,多列表
【发布时间】:2011-11-06 14:44:48
【问题描述】:

我正在为学习者管理系统设计一个架构。

我目前有 LearnerDetails 表,其中存储了以下类别的信息。 - 登录用户帐户详细信息 - 联系方式和家庭住址 - 学习者的居住相关信息,包括国籍信息、留在英国的当前签证详情等 - 学习者当前状态福利相关信息 - 有关学习者当前就业状况的详细信息

我遇到的问题是,当所有这些信息都表示在一个表中时,列数超过 70 列。

我可以做的一件事是,我可以将信息分离到表示上述类别的不同表格中,并将这些表格与它们的父表格 LearnerDetails 关联为 1:1 关系。

我想知道这是否是推荐的方法。 在我看来,1:1 的关系将代表一个过度标准化的数据库。但如果我不这样做,就会导致我的 LearnerDetails 表格有一个巨大的水平表格。

如果您能告诉我您的意见/建议,我们将不胜感激。

【问题讨论】:

    标签: database database-design rdbms er-diagrams


    【解决方案1】:

    只要您有 5NF 或至少 3NF,表中的许多列本质上并没有错。

    但是,有很多例子表明垂直分区 (1::1) 是有意义的 -- take a look at a similar question

    【讨论】:

      【解决方案2】:

      列的宽度是多少?如果您的记录比页面大小更宽,那么拥有一个宽表是一个等待发生的性能问题。

      地址通常不是与人的一对一关系。是的,大多数人只有一个,但并非所有人都如此。 Instcne 的学生有时与他们离异的父母一起兼职。我建议将地址分开。如果您存储电话号码,那么这两个通常不是 1-1 关系。您可能有手机、传真号码、公司号码和家庭电话(固定电话)号码。任何很有可能最终需要处于一对多关系中的东西都应该从一开始就分开。

      如果您确实将表分开并希望强制执行一对一关系,您可以使用父表中的 id 作为子表中的 PK,或者为表和设置使用不同的 Pk FK 字段的唯一索引。不要在没有办法在数据库中强制执行的情况下设置一对一的关系。

      【讨论】:

        【解决方案3】:

        如果这是标准化所需要的,那么拥有 70 列或更多列完全没有问题。您没有提及您使用哪些 rdbms,但大多数都支持至少 255 个字段。

        【讨论】:

        • DBMS 是 SQL Server 2008。是的,它确实支持我需要的列数。我基本上想知道的是这是否是最佳实践。我应该有多个带有相关信息的小表(与父表的 1:1 关联),还是应该有一个水平大的表。 (仅从数据库设计的角度出发,不考虑任何与查询优化相关的反规范化)
        猜你喜欢
        • 2020-05-30
        • 2018-12-07
        • 1970-01-01
        • 2011-12-18
        • 2016-10-03
        • 1970-01-01
        • 1970-01-01
        • 2013-01-24
        • 1970-01-01
        相关资源
        最近更新 更多