Создание таблицы таксономии в MySQL - PullRequest
8 голосов
/ 22 ноября 2010

Я создаю ботаническую базу данных, в которой растения будут организованы по их таксономии:

Жизнь Домен Королевство филюм Учебный класс порядок семья Род Виды

Я подумывал об использовании примера, приведенного в статье Управление иерархическими данными в MySQL , однако он добавляет приведенный выше список в виде записей внутри таблицы .... и я не уверен, что это так это лучшее, что можно сделать, так как у меня будет несколько видов на род и несколько родов на семью и так далее. Что бы вы предложили, это лучший способ решить эту проблему. Заранее спасибо.

Ответы [ 5 ]

11 голосов
/ 22 ноября 2010

Я работал с похожими данными и сделал это в 2 части. В синтаксисе 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.
4 голосов
/ 22 ноября 2010

Я не уверен, что действительно куплю эту статью. Графовые структуры будут необходимы , когда сами категории являются изменяемыми. Например, все внезапные таксономисты решили добавить три новых уровня между родом и видом и т. Д.

Из статьи:

... управление иерархическими данными - это не то, для чего предназначена реляционная база данных.

На самом деле, это именно то, для чего он предназначен:

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

Иерархическая модель данных утратила популярность, поскольку реляционная модель Кодда стала стандартом де-факто, используемым практически во всех основных системах управления базами данных.

Сначала я бы написал представление, объединяющее все ваши таблицы, чтобы у вас были следующие столбцы:

Life Domain Kingdom Phylum Class Order Family Genus Species

Теперь вы можете запрашивать это представление любым способом, и вам не нужно беспокоиться о каких-либо объединениях. Легко :)

2 голосов
/ 16 декабря 2013

Вы можете загрузить полные данные таксономии с http://itis.gov, и данные обновляются более или менее ежемесячно. Предоставляемые ими данные включают в себя Материализованный путь - у каждого вида в базе данных есть строка всех уровней над ней, например строка с хлебными крошками или путь к файловой системе.

Я использовал эти данные для разработки демонстрации в своей презентации Модели для иерархических данных . Я преобразовал материализованные данные пути в Таблицу закрытия.

0 голосов
/ 22 ноября 2010

Существует несколько способов представления иерархических данных в реляционной базе данных, хотя с решением NoSQL может быть проще работать, как упоминалось в @duffymo. Итак, предполагая СУРБД, см. Мой вопрос по теме для перечисления полдюжины возможностей . В вашей ситуации я бы предложил материализованный путь, чтобы облегчить просмотр генеалогического древа. Если иерархия меняется регулярно, я бы, вероятно, также смоделировал бы список смежности и обновил бы материализованный путь, используя триггер.

0 голосов
/ 22 ноября 2010

Звучит больше как график.Интересно, будет ли NEO4J лучшим выбором?

...