【问题标题】:Over Simple Database Schema: Good and Bad points? with example简单的数据库模式:优点和缺点?举个例子
【发布时间】:2010-12-02 17:37:55
【问题描述】:

我为这件事的冗长、胡言乱语道歉,但我凌晨 3 点起床,害怕明天必须去工作并处理这个数据库……感觉不对,但也许我错了,就像事情一样按我的方式完成...请告诉我你的想法。

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

page: id, label, contentid, parentpageid

content: id, xmldata

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

我已经包含了一个大大简化的页面层次结构,类似于本文底部的代码列表。

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

  • 对于每个带有“标签”的“页面” SET(有 3 个)有 16 个 儿童,每个都标有 SECTION 数字。
  • 每个单独的 SECTION 都有一个 名为“关于”的孩子和 名为“信息”的孩子
  • 每个“关于”页面都有一组 标签为:“关于事物”、“关于事物”的孩子 和“关于其他事情”

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

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

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

edit:另一个问题是,如果一个页面有子页面,它的 contentid 会被忽略。浪费空间?

我也很难弄清楚我在树中的什么位置……我在看什么类型的对象?

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

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

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

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

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

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

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

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

谢谢!

【问题讨论】:

    标签: sql mysql database-design schema data-modeling


    【解决方案1】:

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

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

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

    您如何在物理上组织它是另一回事,SQL 无法正确区分逻辑/物理是一个可悲但真实的现实,而且由于 SQL 在那个级别,很多开发者也不知道那个级别。

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

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

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

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

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

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

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

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

    【讨论】:

      【解决方案2】:

      我认为 Erwin 的分析表明,您的团队成员对于如何使用关系数据库存在很多困惑。从您的架构来看,您似乎基本上在数据库中重新创建了一个文件系统。这是相当愚蠢的,你的网络服务器已经有一个。我谦虚地建议您在进一步使用您的系统之前需要重新考虑您的设计或咨询网站设计顾问。如果你继续朝着你现在正在做的方向前进,我认为该项目可能会遇到麻烦,并且可能会浪费大量金钱/时间。

      我认为您对数据以及如何对其建模有更好的了解,但您可能需要经过几次迭代才能将其大部分确定为符合您的要求以及您需要从数据库中获得什么- 驱动的站点系统。

      祝你的数据库工作好运!

      【讨论】:

        【解决方案3】:

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

        【讨论】:

        • 是的,这是个好主意,但我怀疑同事们会拒绝使用多个表带来的“增加的复杂性”。 ://
        • 正如其他 cmets 指出的那样,这是唯一明智的解决方案。如果您的同事无法理解这一点,也许您应该尝试在其他地方寻找其他同事。
        【解决方案4】:

        secoif 之所以称它为关系数据库是有原因的。如果没有多个表并使用连接,那么使用数据库的意义何在,还不如使用平面文件。 您所谓的“其他员工”可以随心所欲地指指点点和大笑,但数据库驱动应用程序的真正威力和有效性是在您开始使用联接和规范化数据时。

        【讨论】:

        • 哈,等等,关键是他们手动运行一个脚本,将所有导航数据呈现到一个 xml 文件中,然后我们将该 xml 加载到我们的 flex 应用程序中并使用它......“将点击保存到数据库”并让应用程序“活泼”......虽然我认为他们没有真正考虑过,因为他们所做的任何保存都是多余的:每次用户点击他们无论如何都必须查询数据库来获取内容,除非他们也想在 xml 中存储 400 页内容......
        • 你这个可怜的灵魂..我不能说我工作的公司在这些事情上更好。我更喜欢保护数据库驱动的应用程序而不是擅长“数据库”sigh
        【解决方案5】:

        你可以像这样创建你的表:

        菜单项:ID、名称
        MenuItemContent:ID,内容
        MenuItemHierarchy:ParentMenuItemId、MenuItemId、ContentId、SortKey

        不过,我通常会这样做:

        MenuItem:ID、名称、ContentId
        MenuItemContent:ID,内容
        MenuItemHierarchy:ParentMenuItemId、MenuItemId、SortKey

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

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2013-09-25
          • 1970-01-01
          • 2014-02-08
          • 2011-01-14
          • 1970-01-01
          • 2010-12-03
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多