Question

我为这个啰嗦，ra ra的道歉而道歉但是我凌晨3点起来不得不明天去上班并处理这个数据库......它只是感觉不对，但也许我错了，就像事情一样按我的方式行事......请告诉我你的想法。

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

page: id, label, contentid, parentpageid

content: id, xmldata

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

我已经包含了一个非常简化的页面层次结构，看起来就像这篇帖子底部的代码清单。

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

对于带有'标签'的每个'页' SET（有3个）有16个孩子，每个都标有SECTION 数字。
每一个SECTION都有一个孩子名字'关于'和a 姓名为“信息”的儿童
每个'关于'页面都有一套儿童贴上标签：'关于事情'，'关于东西' 和'关于其他东西'

请注意，虽然孩子们的标签相同，但他们可能会有不同（但相似）的内容。

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

主要问题是：有一些重复条目和重复的层次结构。

编辑：另一个问题是，如果页面有子节点，则会忽略它的争用。浪费了空间？

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

例如，TASK节点需要以不同于其他节点的方式显示...并且确定节点是否为任务的唯一方法是，它的父标签是“任务”（或“作业”或“去做”）。我尝试使用节点的“深度”，但这不起作用，因为有时需要在同一深度上显示不同的其他项目。

建议的解决方案是添加“类型”字段...然后UI决定如何显示节点（例如，'导航'节点进入主标签栏（例如关于）和任务类型节点a侧边栏中的下拉菜单，但同样，这也感觉不对。

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

他们想要添加'排序顺序'字段来解决此问题。看起来好像要设置很多手动工作，特别是如果他们想要重新排序特定的菜单集...（例如，将一个新的子项插入每个单独的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)
       ...

谢谢！

Answer 1

关于你所陈述的一些事情只是一些想法：

“建议的解决方案是添加”类型“字段......”

如果显然需要对某些商业事物进行“打字”，因为某些地方某种程度上存在某种相关的区别，这些区别在于这种不同的“类型”的对象，那么从关系数据库来看，这是一个关键的指示，即你想要/需要设置多个表（每种类型一个），至少在逻辑层。

你如何组织这种物理，是一个不同的事情，这是一个悲伤但真实的现实，SQL无法在逻辑/物理上做出适当的区分，而且这是一个更加悲伤和真实的现实，因为SQL的失败那个级别，很多开发人员也没有这个级别的线索。

“另外，目前没有方法对项目进行排序。”

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

“他们想要添加'排序顺序'字段来修复此问题。”

对我来说，在“非常愚蠢”和“完全疯狂”之间发生任何声音（取决于此排序字段应包含的内容）。

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

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

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

Answer 2

我认为Erwin的分析表明，您的小组成员之间关于如何使用关系数据库存在很多混淆。根据您的架构判断，您似乎基本上在数据库中重新创建了一个文件系统。这是相当愚蠢的，你的网络服务器已经有一个。我谦虚地建议您在进一步使用系统之前需要重新考虑您的设计或咨询网站设计顾问。如果你继续沿着你现在所做的方向前进，我认为这个项目可能会遇到麻烦，可能会浪费很多钱/时间。

我认为您可以更好地掌握数据以及如何对其进行建模，但是您可能需要经历几次迭代，直到您获得它主要适合您的要求以及您需要的数据库驱动的站点系统。

祝你的数据库工作顺利！

Answer 3

我认为你的内容正在打败自己如果没有数据库的ER图表，请画一个 - 你似乎已经对内容有了合理的把握，并将其标准化。
使用此ERD，您应该能够很容易地解决上面提到的大多数问题。

Answer 4

secoif有一个原因，他们称之为关系数据库。如果没有多个表并使用连接，那么使用数据库有什么意义，也可以使用平面文件。您所谓的“其他员工”可以指出他们想要的所有内容，但数据库驱动的应用程序的真正功能和有效性是您开始使用联接并规范化数据时。

Answer 5

您可以像这样创建表格：

MenuItem：Id，Name
MenuItemContent：Id，Content
MenuItemHierarchy：ParentMenuItemId，MenuItemId，ContentId，SortKey

但通常，我这样做：

MenuItem：Id，Name，ContentId
MenuItemContent：Id，Content
MenuItemHierarchy：ParentMenuItemId，MenuItemId，SortKey

不要重复使用我的菜单项来显示不同的内容。

简单的数据库架构：好与坏？用例子

5 个答案: