Как бы вы смоделировали универсальное хранилище Schema.org?

Question

Я ищу лучший способ смоделировать приложение по всему сайту schema.org.Иерархия Schema.org содержит теперь около 500 различных типов, которые можно использовать для разметки микроданных на веб-сайте: http://schema.org/docs/full.html

Цель состоит в том, чтобы построить общую систему вокруг всех этих вещей, не моделируя 500+.различные таблицы с использованием баз данных SQL по умолчанию.

В качестве начального примера моделирование JobPosting представляется довольно простым для моделирования, поскольку в нем просто есть несколько полей и всего две ссылки на объекты Organization и Place: см. http://schema.org/JobPosting

Какую систему баз данных (SQL, MongoDB, Cassandra, neo4J, Sesame, ...) вы бы предложили для моделирования данных такого типа? Существуют даже некоторые специальные базы данных Graph или RDF, которые могут быть другим вариантом.

Бонусный вопрос: Другая проблема, которая поражает меня в настоящий момент, - это множественное наследование, на котором основаны некоторые объекты, например, http://schema.org/Dentist - это организация LocalBusiness, но также и место, поэтому у него есть поля от нескольких разных родителей.

Итак, я ищу систему с:

• VariaВ столбцах, так как я не хочу моделировать эти миллионы атрибутов, используя SQL-DDL
• Множественное наследование или что-то вроде этого (Mixins)
• Полезная ссылка между записями (например, JobPosting указывает наОрганизация и место, к которому она принадлежит)
• Простые запросы (например, получение всех вакансий для данной организации)

Пожалуйста, дайте мне знать, какая информация поможетнайди лучший ответ.

Answer 1

Я думаю, что MongoDB может подойти, потому что его документы облегчают представление отдельных схем.(решает проблему с переменным столбцом).

Для решения связи имеет смысл хранить только ссылки.Например, в JobPosting вы, вероятно, хотите сохранить OrganizationId и PlaceId, потому что это довольно сложные документы.Это также делает запрос к JobPostings определенной организации тривиальным.

Примечание Иногда встраивание может быть более подходящим, но это сильно зависит от способа обновления ваших документов.В частности, многие объекты могут ссылаться на один и тот же адрес, поэтому изменение адреса должно отражаться везде.Иногда все наоборот.Это ключевой вопрос, на который могут ответить только вы.Это зависит от того, как используется система.

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

Предположим, вы хотите отобразить JobPosting.Теперь вы можете отобразить список свойств, а для «Организация» вы печатаете только «ACME, Inc.»со ссылкой.Эта ссылка отправит вас на страницу с информацией о компании "ACME, Inc."В этом случае ваши запросы очень просты.Единственное, что вам нужно сделать, это скопировать название организации в JobPosting (ненормализация), чтобы его было проще отобразить.

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

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

Единственная оставшаяся проблема - множественное наследование или миксины.Я раньше не использовал ruby, но я думаю, что драйвер mongodb ruby ​​поддерживает миксины.

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