sql - 通过简单的数据库架构:优点和缺点？举个例子

我为这件事的长篇大论道歉，但我凌晨3点就起床了，担心明天要去上班处理这个数据库。。。只是感觉不对，但也许我错了，就像我做的那样。。。请告诉我你的想法。
我们的数据库架构类似于：

page: id, label, contentid, parentpageid

content: id, xmldata

我们在页面表中有大约4000个条目。。。
我已经包含了一个大大简化的页面层次结构，看起来像是本文底部的代码列表。
问题的根源在于数据库中充斥着这样的东西：
对于每一个带有“label”的“page”
一套（有3套）有16套
子项，每个子项都标记有节
数字。
每个部分都有
名为“About”和
名为“Info”的子级
每个“关于”页面都有一组
孩子们贴上标签：“关于事物”，“关于事物”
还有“关于其他事情”
注意：虽然孩子们的标签是相同的，但他们可能有不同（但相似）的内容。
考虑到数据，我对这个模式有一些主要的问题，我想知道我是否合理，是否有一个好的解决方案或者我应该读的东西。
主要问题是：有很多重复的条目和重复的层次结构。
编辑：另一个问题是，如果一个页面有子页面，它的contentid将被忽略。浪费空间？
我也有麻烦，因为很难找出我在树上的位置。。。我在看什么样的东西？
例如，任务节点需要以不同于其他节点的方式显示。。。判断节点是否是任务的唯一方法是，它的父标签是“task s”（或“Jobs”或“ToDo”）。我尝试使用节点的“深度”，但这不起作用，因为有时其他项需要在同一深度上显示不同的内容。
提出的解决方案是增加一个“类型”字段。。。然后用户界面决定如何显示一个节点（例如“Nav”节点进入主选项卡栏（例如About），任务类型节点进入侧边栏的下拉列表），但同样，这也感觉不对。
另外，目前还没有对项目排序的方法。到目前为止，我们很幸运，数据按照他们希望显示的正确顺序进入了数据库，而且到目前为止还没有删除。
他们想添加一个“排序顺序”字段来解决这个问题。似乎有很多手工工作要设置，特别是如果他们想重新排序一个特定的菜单集。。。（例如向每个About节点插入一个新的子节点），尽管我想可以编写一个简单的脚本来完成它。。。虽然我的论点是我应该能够在一个地方改变它，然后它刚刚完成。
我从未见过这样的数据库，但他们声称，所有的数据库都是这样设置的。这就是他们的目的。我是疯了还是这是一个荒谬的方式来建立任何数据库与这种多重复层次结构（也要记住，下面的层次结构有许多较少的重复条目和重复树比真正的页面层次结构）。
老实说，我想建议一个更好的解决方案，但我不确定这是什么，因为在真正的层次结构中有8种不同类型的“About”样式节点，其中一些包含更多节点和更多子节点。。。但孩子们的标签和顺序总是一样的。我需要为每种类型的页面创建一个表吗？
我注意到这似乎也是网站的一个常见问题，他们可能有一堆网页，都有完全相同的孩子集。。。但没办法说：好吧，我希望这一页继承这组孩子，但我希望他们都有不同的内容。现在我想把孩子们重新安排在一个位置，让他们都更新。有没有一个强大的，简单的方法来解决这个问题？

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)
       ...

谢谢！

最佳答案

关于你所说的一些事情，我想说几句：
建议的解决方案是添加一个“Type”字段
如果你的一些业务需要明显地被“打字”，因为某个地方在某种不同的“类型”的Objcts之间存在一些相关的区别，那么从关系数据库的角度来说，这是一个关键的指示，你希望/需要建立多个表（每个类型的表），至少在逻辑层上。
如何在物理上组织它是另一回事，SQL未能正确区分逻辑/物理，这是一个可悲但真实的现实，而且由于SQL在这一级别上的失败，许多开发人员在这一级别上也毫无头绪。
此外，当前没有排序项目的方法
请记住，在逻辑级别上，关系数据库不知道任何排序概念。订购是一个演示问题。dbms/数据库只涉及到其物理设计特性（特别是索引）可用于提供客户机/用户要求的查询项顺序。这些索引是否包含在设计中是一个物理数据库设计决策。
“他们想添加一个‘排序顺序’字段来解决这个问题。”
对我来说，听起来介于“相当愚蠢”和“完全疯狂”之间（取决于这个排序顺序字段应该包含什么）。
“但他们声称，所有数据库都是这样建立的。这就是他们的目的。”
听起来像是根本的无知。但我只读了你的部分，这可能有失偏颇。
“下面的层次结构的重复条目和重复树比实际的页面层次结构少很多”。
我将告诉您“数据库的用途”：它们用于注册事实的陈述/断言。数据库中的每一行代表一个事实陈述，这被认为是对的。现在对于复制品：“如果某件事是真的，那么说两遍也不会使它更真实。”版权所有E.F.Codd。任何数据库都不应该保存任何重复项（当然，这意味着相同的东西）。

关于sql - 通过简单的数据库架构:优点和缺点？举个例子，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1499425/