Эффективный способ хранения и запроса древовидных иерархических данных - PullRequest
9 голосов
/ 08 марта 2012

Пожалуйста, смотрите изображение здесь:

https://picasaweb.google.com/108987384888529766314/CS3217Project#5717590602842112850

Итак, как вы можете видеть из изображения, мы пытаемся сохранить иерархические данные в базе данных. 1 издатель имеет майские статьи, 1 статья имеет много комментариев и так далее. Таким образом, если я использую реляционную базу данных, такую ​​как SQL Server, у меня будет таблица издателя, затем таблица статей и таблица комментариев. Но таблица комментариев будет расти очень быстро и станет очень большой.

Таким образом, есть ли альтернатива, которая позволяет мне эффективно хранить и запрашивать такие данные, как дерево? Как насчет NoSQL (MongoDB)?

Ответы [ 4 ]

4 голосов
/ 08 марта 2012

Вы можете использовать смежные списки для иерархических данных.Это эффективно и легко реализовать.Это работает также с MySQL.Вот ссылка: http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/.

2 голосов
/ 09 марта 2012

Здесь - хороший обзор 8 распределенных баз данных NoSQL и потребностей, которые они удовлетворяют.

Ожидаете ли вы, что напишете больше, чем прочитаете?
Ожидаете ли вы, что вам потребуется доступ к данным с малой задержкой, требуется поддержка высокого уровня параллелизма и высокая доступность?
Вам нужны динамические запросы?
Вы предпочитаете определять индексы, а не отображать / сокращать функции?
Важно ли управление версиями?
Ожидаете ли вы, что будете накапливать периодически изменяющиеся данные, по которым должны выполняться предварительно определенные запросы?
Ожидаете ли вы, что вы будете быстро менять данные с предсказуемым размером базы данных (должен в основном помещаться в памяти)?
Ожидаете ли вы графические, сложные или сложные взаимосвязанные данные?
Ожидаете ли вы, что вам понадобится случайный доступ в режиме реального времени для чтения / записи к данным типа BigTable?

1 голос
/ 29 июля 2015

Я нашел это сообщение SO при поиске того же самого, URL-адрес , опубликованный Phpdevpad , отлично подходит для понимания того, как Модель списка смежности и Модель вложенного набора работать и сравнивать друг с другом.Статья очень поддерживает модель вложенного набора и объясняет многие недостатки модели смежного списка, однако Я был очень обеспокоен массовыми обновлениями, которые мог бы вызвать вложенный метод .

Основным ограничением списков смежности, изложенных в статье, было то, что для каждого уровня глубины требовалось дополнительное самостоятельное соединение.Однако это ограничение легко преодолевается с использованием другого языка (такого как php) и рецессивной функции для поиска детей, как показано здесь: http://www.sitepoint.com/hierarchical-data-database/

фрагмент из URL выше с использованиемМодель списка смежности

<?php
// $parent is the parent of the children we want to see
// $level is increased when we go deeper into the tree,
//        used to display a nice indented tree 
function display_children($parent, $level) {

  // retrieve all children of $parent
  $result = mysql_query('SELECT title FROM tree WHERE parent="'.$parent.'";');

  // display each child
  while ($row = mysql_fetch_array($result)) {

    // indent and display the title of this child
    echo str_repeat('  ',$level).$row['title']."n";

    // call this function again to display this
    display_children($row['title'], $level+1);
  }
}

// $node is the name of the node we want the path of
function get_path($node) {

  // look up the parent of this node
  $result = mysql_query('SELECT parent FROM tree WHERE title="'.$node.'";');
  $row = mysql_fetch_array($result);

  // save the path in this array
  $path = array();

  // only continue if this $node isn't the root node
  // (that's the node with no parent)
  if ($row['parent']!='') {

    // the last part of the path to $node, is the name
    // of the parent of $node
    $path[] = $row['parent'];

    // we should add the path to the parent of this node
    // to the path
    $path = array_merge(get_path($row['parent']), $path);
  }

  // return the path
  return $path;
}
display_children('',0);

Заключение

В результате я теперь убежден, что модель списка смежности будет намного проще в использовании и управлении движением вперед.

1 голос
/ 09 марта 2012

Большая часть проектирования баз данных NOSQL включает в себя сочетание следующих методов:

  • Внедрение - вложение объектов и массивов в документ
  • Связывание - ссылки между документами

Схема, которую вы создаете, зависит от различных аспектов ваших данных. Одним из решений вашей проблемы может быть следующая схема:

db.articles { _id: ARTICLE_ID;  publisher: "publisher name";     ...    }
db.comments { _id: COMMENT_ID; article_id: ARTICLE_ID;    ... }

Здесь издатель встроен в документ статьи. Мы можем сделать это, потому что вряд ли имя издателя изменится. Это также избавляет нас от необходимости искать сведения об издателе каждый раз, когда нам необходим доступ к статье.

Комментарии хранятся в своих собственных документах, где каждый комментарий ссылается на статью. Чтобы найти все комментарии, связанные со статьей, вы можете

db.comments.find({article_id:"My Atticle ID"}]

и для ускорения вы всегда можете добавить "article_id" к индексу

db.comments.ensureIndex({article_id:1})
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...