当前位置：文江博客话题详情

在 MySQL 中创建分类表

发布于 2024-10-03 15:41:10 字数 297 浏览 5 评论 0原文

我正在创建一个植物数据库，其中植物将按其分类法进行组织：

生命领域王国门班级命令家庭属 <

我正在考虑使用文章管理 MySQL 中的分层数据 /a>，但是它将上面的列表添加为表内的记录......我不确定这是否是最好的做法，因为我每个属有多个物种，每个科有多个属，所以在。您的建议是解决这个问题的最佳方法。提前致谢。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

墨落成白 2024-10-10 15:41:10

我使用了类似的数据，并将其分为两部分。在 PostgreSQL 语法中。

首先是分类结构（科、属、种……）：

CREATE TABLE taxonomic_units (
  id         serial        PRIMARY KEY,
  name       varchar(20)   NOT NULL,
  parent_id  integer       REFERENCES taxonomic_units(id)
);

1 | Life    | NULL
2 | Domain  | 1
...
7 | Family  | 6
8 | Genus   | 7
9 | Species | 8

其次是植物数据的描述和存储：

CREATE TABLE taxons (
  id                 serial        PRIMARY KEY,
  suptaxon_id        integer       REFERENCES taxons(id),
  taxonomic_unit_id  integer       NOT NULL REFERENCES taxonomic_units(id),
  name               varchar(50)   NOT NULL,
  authority          varchar(50)
);

100 | NULL | 8 | Ocimum    | L.
101 | 100  | 9 | basilicum | L.
102 | 100  | 9 | gratissim | L.

I worked with similar data, and I made it in 2 parts. In PostgreSQL syntax.

First is taxonomy structure (Family, Genus, Species, ...):

CREATE TABLE taxonomic_units (
  id         serial        PRIMARY KEY,
  name       varchar(20)   NOT NULL,
  parent_id  integer       REFERENCES taxonomic_units(id)
);

1 | Life    | NULL
2 | Domain  | 1
...
7 | Family  | 6
8 | Genus   | 7
9 | Species | 8

Second is description and storing of botanical data:

CREATE TABLE taxons (
  id                 serial        PRIMARY KEY,
  suptaxon_id        integer       REFERENCES taxons(id),
  taxonomic_unit_id  integer       NOT NULL REFERENCES taxonomic_units(id),
  name               varchar(50)   NOT NULL,
  authority          varchar(50)
);

100 | NULL | 8 | Ocimum    | L.
101 | 100  | 9 | basilicum | L.
102 | 100  | 9 | gratissim | L.

回复收藏 0 原文

小嗷兮 2024-10-10 15:41:10

我不确定我是否真的相信那篇文章。当类别本身可变时，需要图形结构。例如，分类学家突然决定在属和种之间添加三个新的级别，等等。

来自文章：

...分层数据的管理不是关系数据库的目的。

实际上，它正是它的用途：

http://en.wikipedia.org/wiki/Hierarchical_database_model

随着 Codd 的关系模型成为几乎所有主流数据库管理系统使用的事实标准，分层数据模型失去了吸引力。

我首先会编写一个连接所有表的视图，以便将这些表作为列：

Life Domain Kingdom Phylum Class Order Family Genus Species

现在您可以以任何您喜欢的方式查询该视图，而不必担心任何连接。简单 :)

I'm not sure I really buy into that article. Graph structures would be needed when the categories itself are mutable. Such as, all the sudden taxonomists decided to add three new levels between genus and species, and so on.

From the article:

... the management of hierarchical data is not what a relational database is intended for.

Actually, its exactly what it is intended for:

http://en.wikipedia.org/wiki/Hierarchical_database_model

The hierarchical data model lost traction as Codd's relational model became the de facto standard used by virtually all mainstream database management systems.

I would first write a view that joined all of your tables so that you would have these as your columns:

Life Domain Kingdom Phylum Class Order Family Genus Species

Now you can query that view any way you like and not have to worry about any joins. Easy :)

回复收藏 0 原文

撩发小公举 2024-10-10 15:41:10

您可以从 http://itis.gov 下载完整的分类数据，该数据或多或少每月更新一次。他们提供的数据包括一个物化路径——数据库中的每个物种都有一个包含其之上所有级别的字符串，例如面包屑字符串或文件系统路径。

我在演示文稿中使用这些数据设计了一个演示分层数据模型。我将物化路径数据转换为闭包表。

回复收藏 0 原文

北渚 2024-10-10 15:41:10

听起来更像是一张图表。我想知道 NEO4J 是否是更好的选择。

回复收藏 0 原文

去了角落 2024-10-10 15:41:10

有多种方法可以在关系数据库中表示分层数据，尽管 NoSQL 解决方案可能更容易使用，如 @duffymo 提到的。因此，假设使用 RDBMS，查看我的问题关于该主题列举了六种可能性。对于您的情况，我会引导一条具体化的路径，以便轻松查看家谱。如果层次结构定期更改，我可能还会将模型建模为邻接列表，并使用触发器更新具体化路径。

回复收藏 0 原文

~没有更多了~