需要数据库结构建议

Question

我目前正在一个包含产品目录的网站上工作.我对数据库设计有点新意,所以我正在寻找有关如何最好地做到这一点的建议.我熟悉关系数据库设计,所以我理解"多对多"或"一对多"等(在大学里学习了很好的数据库课程).以下是项目可能归类为以下内容的示例:

Propeller -> aircraft -> wood -> brand -> product.

不要试图写出我到目前为止的内容,只需快速浏览一下我从phpmyadmin设计器功能创建的图像.

替代文字http://www.usfultimate.com/temp/db_design.jpg

现在,这一切看起来都很精致,直到我意识到"木头"这个类别也将在螺旋桨 - >汽艇 - >(木头)下使用.这意味着,每次我想在不同的父母下使用它时,都必须重新创建"木头".这不是世界末日,但我想知道是否有更好的方法来解决这个问题.

此外,我试图让这件事情尽可能保持活力,以便客户可以根据需求的变化组织他的目录.

*编辑.正在考虑创建一个"标签"表.所以我可以将标签"wood"或"metal"或"50inch"分配给1到多个项目.我仍然会为主要类别保留一个育儿类型的东西,但这样的类别不会那么深,并且不会有重复.

Answer 1

首先,用户界面:作为用户,我讨厌在严格分层的方式组织的目录中搜索产品.我永远不记得在什么子亚子......类别中有一种"异国情调"的产品,这迫使我浪费时间探索"有希望"的类别,只是为了发现它被分类为(对我而言,至少)奇怪的方式.

什么凯文PENO建议是一个很好的建议,被称为层面浏览.正如Marcia Bates在After the Dot-Bomb中写道:这次正确获取网络信息检索," ..分面分类是分层分类,因为关系数据库是分层数据库...... ".

从本质上讲,分面搜索允许用户从他们喜欢的任何"方面"开始搜索您的目录,并让他们过滤信息,选择搜索中的其他方面.请注意,与通常构思标记系统的方式相反,没有什么能阻止您按层次结构组织这些方面.

为了快速了解切面搜索是什么,有一些演示要探索 弗拉门戈搜索界面项目 - 搜索流程的界面.

二,应用逻辑:什么Manitra建议也是一个很好的建议(据我所知),即分离nodes,并links在不同的关系树/图形.他称之为"祖先表"(这是一个更好的直观名称)被称为有向无环图(DAG)(可达性关系)的传递闭包.Manitra说,除了性能之外,它还大大简化了查询.

但我建议查看这样的"祖先表"(传递闭包),以便更新是实时和增量的,而不是批处理作业的周期性.在我对图集查询语言的回答中提到的论文中有SQL代码(但我认为需要对特定的DBMS进行一些调整):数据建模问题.特别是,请查看在SQL中维护图的传递闭包(.ps - postscript).

产品 - 分类关系

Manitra的第一点也值得强调.

他所说的是产品和类别之间存在多对多的关系.即:每个产品可以是一个或多个类别,并且在每个类别中可以有零个或多个产品.

给定关系变量(relvars)产品和类别这种关系可以表示为例如具有至少属性P#和C#的relvar PC,即与相应产品和类别的外键关系中的产品和类别编号(标识符)数字.

这是对类别层次结构管理的补充.当然,这只是一个设计草图.

在SQL中进行分面浏览

实现"分面浏览"的一个有用概念是关系划分,甚至是关系比较(参见链接页面的底部).即将PC(产品 - 类别)除以从用户(构面导航)中选择的(不断增长的)类别列表,仅获得这些类别中的产品(当然,假定类别不是全部互斥,否则选择两个类别将获得零产品).

基于SQL的DBMS通常缺少这个操作符(除法和比较),因此我在下面给出一些有趣的文章来实现/讨论它们:

• 关于制定关系部门的可靠性(来自FIE 2003会议指数的 .pdf );
• 一种更简单(和更好)的关系划分SQL方法(.pdf来自Journal of Information Systems Education - Contents Volume 13,Number 2(2002));
• 通过除法处理频繁项集发现查询并设置包含连接运算符 ;
• 重写包含分部操作员的查询的法律 ;
• 关系数据库中通用量化的算法和应用 ;
• 在面向对象和对象关系数据库中通过通用量化优化查询 ;
• (需要ACM访问)关于代数中的除法和集合连接的复杂性 ;
• (需要ACM访问)在大型数据库中进行通用量化的快速算法 ;

等等...

我不会在这里详细介绍,但是类别层次结构和方面浏览之间的交互需要特别小心.

关于"平坦度"的题外话

我简要地看了一下由Pras链接的文章,在MySQL中管理分层数据,但是在介绍中的这几行后我停止了阅读:

介绍

大多数用户曾经在SQL数据库中处理过分层数据,毫无疑问,他们了解到分层数据的管理不是关系数据库的用途.关系数据库的表不是分层的(如XML),而只是一个平面列表.分层数据具有父子关系,该关系不是在关系数据库表中自然表示的....

要理解为什么这种对关系平坦性的坚持只是无意义,想象一下三维笛卡尔坐标系中的一个立方体:它将由8个坐标(三元组)识别,比如P1(x1,y1,z1),P2(x2,y2) ,z2),...,P8(x8,y8,z8)[这里我们不关心这些坐标的约束,因此它们实际上代表了一个立方体].

现在,我们将这些坐标(点)集合成一个关系变量,我们将命名这个变量Points.我们将表示下面的关系值Points:

Points|  x |  y |  z |
=======+====+====+====+
       | x1 | y1 | z1 |
       +----+----+----+
       | x2 | y2 | z2 |
       +----+----+----+
       | .. | .. | .. |
       | .. | .. | .. |
       +----+----+----+
       | x8 | y8 | z8 |
       +----+----+----+

仅仅以表格方式表示这个立方体是否被"夷为平地"？关系(值)与表格表示相同吗？

关系变量假定为n维离散空间中的点集值,其中n是关系属性的数量("列").对于n维离散空间,它是什么意思"平坦"？正如我上面写的那样,只是胡说八道.

不要误会我的意思,SQL确实是一种设计糟糕的语言,基于SQL的DBMS充满了特性和缺点(NULL,冗余......),特别是坏的,DBMS-as-哑商店类型(没有参考约束,没有完整性约束,......).但这与关系数据模型幻想的局限性无关,相反:它们越远离它,结果就越糟糕.

特别是,关系数据模型,一旦你理解它,就不会在表示任何结构,甚至层次结构和图形方面产生任何问题,正如我在上面提到的已发表论文中的详细描述.即使SQL可以,如果你掩饰其缺陷,也可以更好地遗漏一些东西.

关于"嵌套集模型"

我浏览了那篇文章的其余内容,我对这种逻辑设计并没有特别印象:它建议将两个不同的实体,节点和链接混为一种关系,这可能会导致尴尬.但我并不倾向于更彻底地分析那个设计,对不起.

编辑: Stephan Eggermont在下面的评论中反对" 平面列表模型是一个问题.它是实现的抽象,使得性能难以实现...... ".

现在,我的观点恰恰是:

1. 这个"平面列表模型"是一个幻想:只是因为一个布局(代表)关系作为表("平面列表")并不意味着关系是"平面列表"(一个"对象"及其表示不是一回事);
2. 逻辑表示(关系)和物理存储细节(水平或垂直分解,压缩,索引(散列,b +树,r树,...),聚类,分区等)是不同的; 关系数据模型(RDM)的一个要点是将逻辑与"物理"模型分离(对DBMS的用户和实现者都有优势);
3. 性能是物理存储细节(实现)的直接结果,而不是逻辑表示(Eggermont的评论是逻辑 - 物理混淆的典型例子).

RDM模型不以任何方式约束实现; 一个人可以自由地实现元组和关系.关系不一定是文件,元组不一定是文件的记录.这种对应是一种愚蠢的直接图像实现.

不幸的是,基于SQL的DBMS实现常常是愚蠢的直接图像实现,并且在各种情况下性能都很差 - 存在OLAP/ETL产品来弥补这些缺点.

这正在慢慢改变.有商业和自由软件/开源实现,最终避免这个基本陷阱:

• Vertica,是...的商业继承者
• C-Store:面向列的DBMS ;
• MonetDB ;
• LucidDB ;
• Kdb在某种程度上;
• 等......

当然,关键不在于必须存在"最优"的物理存储设计,而是基于关系代数/计算(以及SQL是一个不好的例子)或者更多的基于关系代数/计算的好的声明性语言可以抽象出任何物理存储设计.直接在逻辑编程语言上(例如Prolog,请参阅我的答案" prolog to SQL converter "问题).一个好的DBMS应该根据数据访问统计(和/或用户提示)即时更改物理存储设计.

最后,在Eggermont的评论中,声明" 关系模型在云和前驱者之间变得格格不入. "是另一个无稽之谈,但我不能在这里给出反驳,这个评论已经太长了.

Answer 2

在数据库中创建分层类别模型之前,请先阅读本文,其中解释了问题和解决方案(使用嵌套集).

总而言之,使用简单的parent_category_id不能很好地扩展,并且您将很难编写高性能的SQL查询.答案是使用嵌套集,使您可以将多对多类别模型可视化为嵌套在其他集合中的集合.