存在项目继承时处理订购项目的数据库表设计答案

【问题标题】：Database table design to handle ordering items when there is inheritance of items存在项目继承时处理订购项目的数据库表设计
【发布时间】：2013-04-12 02:32:34
【问题描述】：

我对数据库有以下要求。它需要能够存储物品。项目有一个 id、标识符和标题。每个项目可以有零或多个小部件和零个或多个 dodads。每个小部件和每个 dodad 都有一个标题和类型。 Dodads 也有一个默认值。还有顺序小部件和 dodas 需要保存。

我有以下表格可以做到这一点：

items  widgets  dodads
-----  -------  ------
id     id       id
ident  itemId   itemId
title  title    title
       type     type
       order    order
                default

所以现在我希望能够拥有继承权。很简单，加个 parentId 到 items 表。现在的问题是小部件中的订单列和 dodad 表。

继承的顺序应该在父项必须在 tha 中有效与父级相同的顺序，但子级的项目可以是interwhoven。那是类似以下的东西应该是可行的：

P1
P2
C1
C2
P3
P4
C3

所以问题是如何存储小部件和 dodads 的整体顺序？一世假设我需要另一张桌子，但不确定最好的方法。这将是如果表结构可以处理多个父母，那就太好了。

【问题讨论】：

引入一个Level {0, 1, 3, ...} -- 节点离根有多远；对于同一级别的节点，例如 {1.1, 1.2 ..}。顺便说一句，添加ParentID 来创建树是一种“幼稚的方式”；搜索nested sets, closure table, path enumeration, levelled hierarchy..

标签： mysql database-design

【解决方案1】：

订单不是一个数据库概念，它是一个表示概念（就像数据在屏幕或报告中的显示方式一样）。听起来您正在根据一种特定的数据向用户显示的方式设计存储结构，这通常表明您的数据设计有问题。我无法确定您到底在寻找什么，因为您的 P1/P2/C1/C2 示例没有显示任何小部件或装饰物，但我认为这就是您遇到问题的级别。

半相关：如果小部件和装饰物之间的唯一区别是“默认”列，为什么不将它们与其他类型或类别列放在同一个表中？如果问题的一部分是在同一个列表中对小部件和装饰物进行排序，这将有所帮助。

【讨论】：

订单是显示问题，但需要存储该订单。小部件和 dodad 之间有更多区别，但我只是为一个简单的示例做了一个细微的区别。 P/C 清单更说明父或子小部件或 dodad 有自己的顺序，但可以混合使用。它的混合顺序比我不知道如何保存。