Подходят ли тройные магазины RDF для повседневного программирования? - PullRequest
0 голосов
/ 23 марта 2010

Мне это очень нравится, и я хотел бы использовать их для всего. Почему создание тройных хранилищ RDF для повседневного программирования (сущностей / таблиц), таких как контакты, клиенты, компании и т. Д., Было бы плохой идеей.

Существуют ли короткие проблемы в технологии, с которыми я не сталкивался? Я был обеспокоен поиском данных, но я думаю, что это покрыто SPARQL.

Ответы [ 5 ]

2 голосов
/ 05 мая 2011

Одна проблема, которая еще не упоминалась, заключается в том, что обновление триплетов для отражения изменяющихся данных часто является более трудоемким, чем для СУБД или OODBMS, поскольку отсутствует понятие «объект» или «строка» - только триады и ресурсы. Поэтому удаление объекта домена требует осторожности, иначе у вас останется много мусора в тройном магазине. Отсутствие каскадных удалений является тесно связанной проблемой.

С другой стороны, RDF может быть полезен даже для повседневных приложений, потому что вы можете гибко добавлять новые подклассы, отношения или под-отношения между сущностями, не обязательно нарушая код, и легко добавлять аннотации, комментарии и т. Д. К ресурсам.

2 голосов
/ 16 мая 2010

Одним из недостатков, с которыми мы столкнулись при использовании тройного хранилища RDF для общего программирования, является то, что большинство механизмов не поддерживают агрегирование в запросах (min, max, group by).

Контрольный список, который мы используем для выбора между RDBMS, следующий

СУБД, если

  • статическая схема
  • очень большой объем данных
  • экспорт RDF не требуется
  • Требуется поддержка Lucene (например, легко с помощью Hibernate Search)
  • строгие требования к согласованности данных (деньги и т. Д.)

RDF, если

  • нефиксированная или динамическая схема
  • малый или большой объем данных
  • Необходим экспорт RDF
  • несоответствующие требования к согласованности данных

Рефакторинг схем RDFBMS для текущих проектов может оказаться довольно трудоемким, если у вас нет правильных инструментов.

Поддержка Lucene также предоставляется некоторыми механизмами RDF, но не так хорошо документирована и поддерживается, как в случае Hibernate Search.

Масштабируемость движков RDF также неуклонно улучшается, когда идеи стороны NoSQL включаются в движки RDF, но если использовать стандартные движки Jena и Sesame, это разделение все еще вполне допустимо.

2 голосов
/ 25 марта 2010

Время запросов, как правило, намного медленнее, чем для обычных БД, даже с простыми запросами.Кроме того, многие хранилища RDF не поддерживают стандартные функции БД, такие как транзакции, восстановление после сбоя, ...

2 голосов
/ 23 марта 2010

Нет универсальных инструментов. Тройные магазины сегодня подходят и подходят для одних задач, а не для других.

A аналогичный вопрос задавался на semanticoverflow.com, и общий ответ был таким же: «используйте все, что подходит».

1 голос
/ 24 марта 2010

В дополнение к ответу Петериса есть некоторые ключевые различия между тем, как вы моделируете данные для Triple Store, и другими методами, такими как ООП, реляционные базы данных, XML, например. строки, классы, свойства и т. д.

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

Люди склонны характеризовать тройные хранилища как базы данных без схемы, но реально, если вы не используете какую-либо форму схемы / онтологии, тогда они не особенно полезны. Если вы хотите использовать SPARQL для получения информации, в магазине должны быть шаблоны схем, к которым вы можете писать запросы.

Лично я бы по-прежнему использовал реляционные базы данных для многих вещей и до сих пор делаю, в то время как я использую RDF и тройные хранилища для растущего количества вещей, которые не означают, что я готов выбросить то, что работает хорошо.

В качестве конечной точки, даже если вы в настоящее время используете реляционную базу данных, есть такие технологии, как DB2RDF , которые могут преобразовывать реляционные базы данных в RDF, чтобы вы могли придерживаться БД на данный момент и затем экспортировать база данных для RDF в будущем по желанию

...