sql - 以简单的数据库架构 : Good and Bad points? 为例

Question

我为这件事的冗长、无理取闹而道歉，但我凌晨 3 点起床，害怕明天必须去上类并处理这个数据库……感觉不对，但也许我错了，就像事情按照我的方式做... 请告诉我你的想法。

我们的数据库架构类似于:

page: id, label, contentid, parentpageid

content: id, xmldata

我们在页表中有大约 4000 个条目......

我已经包含了一个大大简化的页面层次结构，它看起来像这篇文章底部的代码列表。

问题的根源在于数据库充满了这样的事实:

对于每个带有“标签”的“页面”
SET(有 3 个)有 16 个
child ，每个都标有 SECTION
数字。

每个 SECTION 都有一个
名为“关于”的 child 和
名为“信息”的 child

每个“关于”页面都有一组
标签为:“关于事物”、“关于事物”的 child
和“关于其他东西”

请注意，尽管 children 的标签相同，但他们可能会有不同(但相似)的内容。

考虑到数据，我对这个架构有一些主要问题，我想知道我是否有道理，是否有一个好的解决方案或我应该阅读的内容。

主要问题是:有很多重复的条目和重复的层次结构。

编辑:另一个问题是，如果一个页面有 child ，它的 contentid 会被忽略。浪费空间？

我也很难弄清楚我在树中的位置......我在看什么类型的物体？

例如，TASK 节点的显示方式需要与其他节点不同......并且确定节点是否为任务的唯一方法是它的父节点标签是否为“Tasks”(或“Jobs”或“ToDo”) .我尝试使用节点的“深度”，但这不起作用，因为有时其他项目需要在同一深度上进行不同的显示。

提出的解决方案是添加一个“类型”字段......然后用户界面决定如何显示一个节点(例如“导航”节点进入主选项卡栏(例如关于)，任务类型节点在下拉菜单中侧边栏)，但同样，这也感觉不对。

此外，目前没有对项目进行排序的方法。到目前为止，我们很幸运，数据以他们想要显示的正确顺序进入数据库，到目前为止还没有删除。

他们想添加一个“排序顺序”字段来解决这个问题。设置似乎需要很多手动工作，特别是如果他们想要重新排序特定的菜单集......(例如，在每个 About 节点中插入一个新子节点)，虽然我想可以编写一个简单的脚本来做到这一点...虽然我的论点是我应该能够在一个位置更改它，然后它就完成了。

我从未见过这样设置的数据库，但他们声称，这就是所有数据库的设置方式。这就是他们的目的。我是疯了还是这是一种荒谬的方式来设置具有如此多重复层次结构的任何数据库(还要记住，下面的层次结构比真实的页面层次结构具有更少的重复条目和重复树)。

老实说，我想提出一个更好的解决方案，但我不确定那是什么，因为在真正的层次结构中有 8 种不同类型的“关于”样式节点，其中一些包含更多节点和更多子节点......但是 children 的标签和排序总是相同的模式。我是否需要为每种类型的页面创建一个表格？

我注意到这似乎也是网站的一个常见问题，他们可能有一堆页面，所有页面都有完全相同的一组子项......但没有办法说:好的，我希望这个页面继承这个集合 child ，但我希望他们都有不同的内容。现在我想将 child 重新排列在一个位置并让它们全部更新。有没有一种强大、简单的方法来解决这个问题？

SET1
    SECTION1
        -About 
             -About Things
             -About Stuff
             -About Other Stuff
        -Info
        -Tasks
             -A
             -B
             -C
              ...
             -H
        -Data
    SECTION2
        -About
             -About Things
             -About Stuff
             -About Other Stuff
        -Info
        -Tasks
             -A
             -B
             -C
              ...
             -H
        -Data
...
    SECTION16

SET2
    SECTION1
        -About
             -About Things
             -About Stuff
             -About Other Stuff
        -Info
        -Jobs
             -1
             -2
             -3
              ...
             -8

        -ToDo
             -A
             -B
             -C
              ...
             -H
        -Other Data
    SECTION2
        -About
             -About Things
             -About Stuff
             -About Other Stuff
        -Info
        -Jobs
             -1
             -2
             -3
              ...
             -8

        -ToDo
             -A
             -B
             -C
              ...
             -H
        -Other Data
SET3 (Exact same setup as SET2)
       ...

谢谢!

Answer 1

关于你所说的一些事情的一些想法:

“提出的解决方案是添加一个“类型”字段......“

如果明显需要对您的某些业务事物进行“类型化”，因为在某些地方，这种不同“类型”的对象之间存在一些相关的区别，那么从关系数据库的角度来看，这是您想要/需要的关键指示设置多个表(每种类型一个)，至少在逻辑级别。

如何在物理上组织它是另一回事，SQL 未能正确区分逻辑/物理是一个可悲但真实的现实，而且由于 SQL 在该级别上的失败，这是一个更加可悲和更真实的现实，许多开发人员也不知道那个级别的线索。

“另外，目前还没有办法对元素进行分类。”

请记住，在逻辑级别，关系数据库不知道任何排序概念。订购是一个演示问题。 dbms/数据库仅涉及其物理设计特征(特别是索引)可用于提供客户/用户要求的查询项目排序。设计中是否包含此类索引是物理数据库设计决策。

“他们想添加一个‘排序顺序’字段来解决这个问题。”

对我来说听起来介于“非常愚蠢”和“完全疯狂”之间(取决于此排序顺序字段应该包含的内容)。

“但他们声称，这就是所有数据库的设置方式。这就是他们的目的。”

对我来说听起来像是根本的无知。但我只看了你的部分故事，这可能是有偏见的。

“下面的层次结构比真正的页面层次结构具有更少的重复条目和重复树”。

我会告诉你“数据库的用途是什么”:它们用于注册陈述/事实断言。数据库中的每一行都代表一个事实陈述，这被认为是真实的。现在对于重复项:“如果某件事是真的，那么说两次不会使它更真实。”版权所有 E.F.Codd。任何数据库都不应该保存任何重复项(当然，它们的意思是相同的)。