我是数据库设计的新手,只是想了解一下我是否会以合理的方式解决这个问题。我正在构建一个简单的MySQL数据库,用户可以通过该数据库将项目上传到以前存在的(不变的)分层树。
举个简单的例子:
第1节
分部1.1
细分1.1.1
细分1.1.2
分部1.2
细分1.2.1
细分1.2.2
第2节
分部2.1
细分2.1.1
细分2.1.2
分部2.2
细分2.2.1
细分2.2.2
树的结构不会改变,用户只需上传属于细分的产品(行业特定的组织大量产品的方式)。我已经对邻接列表和嵌套集进行了研究,但我倾向于3个独立的表,每个表引用其父父键(看到树的顶层几乎不会改变)。当上传新产品时,它将引用其所有三个父母(如果它是根据细分1.1.2提交的,则它必然是第1部分第1部分的一部分)。最终的树将有4个部分,每个部分有10个分区,每个分区有10个分区。这是否有意义作为一种启动策略?
与数据库的交互或多或少局限于输入信息并对其进行准确分类,然后能够显示已在部门,部门或细分中提交了多少产品。该库将显示在一系列下拉列表中,单击列表项将显示存储的信息。
对任何文献/教程的推荐或参考将不胜感激!
答案 0 :(得分:2)
由于类别(部分)或多或少是静态的,您可以做的是为每个类别分配一个“高”和“低”数字,例如
catid name low high
1 Section1 1 20
2 Div1.1 2 10
3 Div1.2 11 19
4 Section2 21 40
5 Div2.1 22 29
6 Div2.2 30 39
然后有一个单独的内容表:
id catid content
1 2 fileA
2 2 fileB
3 5 fileC
要查询第1部分下的所有项目,您只需查询类别中1到20之间高低的所有项目。要获取Div2.1(及以下)中的所有项目,您将查询所有项目具有高和低类别的类别在22到29之间。这样可以很容易地跟踪子类别下的项目数。
我忘记了这个实际方法的名称(如果有确定的方法),但我已经多次使用它了。对于没有太大变化的结构,它比传统的parent_id-child_id类型结构更容易使用。
答案 1 :(得分:2)
一个好的解决方案是有一个递归表。
在StackOverflow上查看此帖子:Hierarchical Data in MySQL
这样,您的设计将支持在树下更多级别。
关于此主题的其他有趣文章:
Managing Hierarchical Data in MySQL
Hierarchical data in MySQL: parents and children in one query
Hierarchical data in MySQL: easy and fast
Recursion-less storage of hierarchical data in a relational database
答案 2 :(得分:2)
因为“树的结构不会改变”,您需要section
,division
和subdivision
表格(也是产品)。
create table section (
id int primary key,
name varchar(100)
);
create table division (
id int primary key,
name varchar(100) ,
section_id int references section
);
create table subdivision (
id int primary key,
name varchar(100) ,
division_id int references division
);
create table product (
id int primary key,
name varchar(100) ,
subdivision_id int references subdivision
);
对于其他requerimets,例如:
您将寻找父子解决方案,例如:
create table tree (
id int primary key,
parent_id int null references tree,
name varchar(100)
);
create table product (
id int primary key,
name varchar(100) ,
subdivision_id int references tree
);
答案 3 :(得分:0)