Использование графа, как основы для создания рубрикатора

[multik]

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

Не решив этих задач — контент для «свежего» классификатора придётся писать самому, что ведёт накладные расходы на содержание дорогого журналистского отдела. Так как это не всегда возможно, то оптимальным будет предоставление контента самими пользователями, но размещаться в «контентной пустыне», чистом рубрикаторе, никто не захочет, поэтому придётся добыть где-то стартовый контент. И даже если вы договоритесь с партнёрами, всё равно встанет задача синхронизации классификаторов.

Также важно понимать, что основная бизнес-модель зарабатывания денег, в таких проектах — это реклама, и весьма вероятно, что придётся подстраиваться под изменение внешних факторов — попросту менять рубрикатор в направлении, которое заранее предсказать нельзя. Поэтому более ценным будет именно умение изменять и синхронизировать существующие классификаторы на ходу (за разумное время) с минимальными потерями знаний в системе.

Идеальный рубрикатор — это утопия, если вы работаете в издательстве журнала лет 7 — вы это и сами понимаете.

[AHrEJI]

Я тоже выбрал эту модель для построения рубрикатора.
Единственное отличие — у меня еще существуют поясняющие теги к каждой рубрике (и к вершинам и к листьям)

[DimonSmart]

интересная мысль, но отличаются ли у вас листья от описаний?

[AHrEJI]

Например, лист называется Галантерейные товары, а в тегах у него: Сумки, Кошельки и т.д.

Соответственно в поиске набираем Сумки, получаем лист Галантерейные товары и все компании, попадающие под эту сферу.

[VGrigoryev]

Как я понимаю, в терминах данной статьи, ваши Галантерейные товары это и есть узел, у которого будут «описывающие» его листья — Сумки, Кошельки и т.д.

[fStrange]

Видимо это специализированный набор «листьев», хранящийся в отдельной таблице.

В данной статье каждый лист одновременно является возможным узлом, у комментатора же «листья» не являются узлами.

[grin]

а подскажите как хранить такие графы в базе? есть ли готовые алгоритмы, типа nestedsets для деревьев?

[interrupt_controller]

как список ребер, где в полях будут указаны вершины, которые соединяет ребро

[interrupt_controller]

а вершины — это id записей

[interrupt_controller]

*рубрик (простите за 3 комментария подряд)

[multik]

смотря в какой базе, в Cache, например, очень легко хранить графы и деревья — ибо она древовидная БД — никаких алгоритмов не требуется.
В реляционной базе придётся немного извратиться. Вот пример «изврата» habrahabr.ru/blogs/sql/43955/ немного не в тему но всё же.

[interrupt_controller]

в реляционной см. выше, никакого изврата. Извращаться будет приложение, которое будет подключаться к БД, чтобы забрать данные. Хотя там тоже все просто

[multik]

одно дело просто — а другое — естественно, и хранение графа в древовидной БД естественнее чем в реляционной

[interrupt_controller]

это да, но не всегда есть возможность использовать древовидную БД

[DimonSmart]

В базе всё просто: две таблицы. Сущности и связи.
Причем сущности могут существовать отдельно от связей. Это чтобы можно было отдельно добавлять понятия. Например встретили какой то новый термин — добавали, просто чтобы не забыть про него. А уж потом привязали к соответствующим узлам и отдельно их структурировать. Лист превращается в узел простым добавлением связи. Для удобства показа и обработки там конечно хранится флажок, но это уже мелкая оптимизация.

[DimonSmart]

Видео в котором народ воюет с рубрикатором