代码之家  ›  专栏  ›  技术社区  ›  Ross

如何处理“扩展”表

  •  1
  • Ross  · 技术社区  · 15 年前

    我正在设计一个涉及“页面”的应用程序,它有许多“块”,其中有几种类型的块。不过,我正在努力寻找一种好的方法将这些数据保存在数据库中。我想有一种流行的方法可以做到这一点,下面是我正在考虑的两种方法:

    接近一号

    • Pages表
      • 身份证件
      • 用户
    • 阻碍
      • 身份证件
      • 页码(块.页= 页码.id)
      • 块id(Blocks.block\标识= nBlocks.id编号其中n=块(U型)
    • 文本块
      • 身份证件
      • 文本特定属性

    这样做的好处是所有类型的块(创建、更新、页面、标题、顺序)的公共属性都保存在一个地方。您也不必查询每个块类型表来检查当前页的块,因为您将拥有这个“索引”。缺点是它在查找块时可能会变得有点混乱,但这取决于它的正确实现(查找页的所有块、按块类型分组、对每个块类型运行查询)。

    方法二

    • 文本块
      • 身份证件
      • 页码
      • 正文,文本特定项
      • 创建、更新、订购
      • 身份证件
      • 列出特定项目
      • 创建、更新、订购等。

    update where order in any other block != $order )每个表都必须有相同的created、updated等字段,如果需要更改这些字段,就需要付出一些努力。更大的问题是,必须为每个页面查询每个特定于块的表,而不是只查询块表,因为块表肯定有页面的块。

    还有第三种更好的方法吗?我认为最好的方法是第一种(至少比第二种更正常化,而表逻辑不是这样) 那个

    1 回复  |  直到 15 年前
        1
  •  1
  •   y34h    15 年前

    方法二有一个巨大的缺点:排序。

    我会采取一种方法,或者这样:

    • 一页一页
    • 阻碍
      • 身份证件
      • 页码
      • 文本特定项(全部可为空)
      • 列出特定项(所有项都可以为空)
      • 创建、更新、订购

    赞成的意见: 与方法一相同

    欺骗:

    • 如果你有很多块类型或者每种类型有很多特定的项,你会有一个很宽很混乱的表。
    • 一切都是可以为空的,所以您不能仅仅通过查看表来确定哪些字段是必需的


    额外小费