Лучшие практики для доступа к бессхемным данным?
Я играю с RDF, и в особенности как получить доступ к информации, хранившей в rdf устройстве хранения данных. Огромной разницей от традиционной реляционной базы данных является отсутствие предопределенной схемы: в реляционной базе данных Вы знаете, что таблица имеет те столбцы, и можно технически отобразить каждую строку на экземпляр класса. Класс имеет четко определенные методы и четко определенные атрибуты.
В бессхемной системе Вы не знаете, какие данные связаны с данной информацией. Это похоже на наличие таблицы базы данных с произвольным и не предопределенным числом столбцов, и каждая строка может иметь данные в любом числе этих столбцов.
Подобный Картопостроителям ObjectRelational, существует Объект картопостроители RDF. RDFAlchemy и SuRF являются двумя, которые я играю прямо сейчас. В основном они предоставляют Вам объект Ресурса, методы которого и атрибуты предоставлены динамично. Это отчасти имеет смысл... однако, дело не в этом легкий. Во многих случаях Вы предпочитаете иметь четко определенный интерфейс и иметь больше контроля над тем, что продолжается, когда Вы устанавливаете и получаете данные по своему объекту модели. Наличие такого универсального доступа делает вещи трудными в некотором смысле.
Другая вещь (и самый важный) я отметил, то, что, даже если в целом, бессхемные данные, как ожидают, предоставят произвольную информацию о ресурсе, на практике Вы более или менее знаете "классы информации", которые имеют тенденцию быть вместе. Конечно, Вы не можете исключить присутствие дополнительной информации, но это, в некоторых случаях, является исключением, а не нормой, хотя исключение достаточно разумно, чтобы быть слишком разрушительным для строгой схемы. В rdf представлении статьи (например, как в RSS/Atom-лентах) Вы знаете условия своих описанных ресурсов, и можно отобразить их на четко определенный объект. Если Вы предоставляете дополнительную информацию, можно определить расширенный объект (наследованный от основного) для обеспечения средств доступа расширенной информации. Так в некотором смысле Вы имеете дело с бессхемными данными посредством ориентированных объектов "схемы", можно расшириться, когда Вы хотите видеть определенную дополнительную информацию, Вам интересно о.
Мой вопрос относительно Вашего опыта о методах использования реального мира бессхемного хранения данных. Как они отображаются на объектно-ориентированный мир так, чтобы можно было использовать его умело и не идя также близко к "чистому металлу" бессхемного устройства хранения данных? (в терминах RelDB, не используя слишком много SQL и непосредственно смешивая со структурой таблицы)
Доступ обречен быть очень универсальным (например, SuRF, "включенный - в атрибутах", является самым высоким, самым специализированным уровнем, Вам, возможно, придется получить доступ к Вашим данным), или специализировавший классы для определенных согласованных удобных схем также хороший подход, представляя однако риск наличия быстрого увеличения классов для доступа к новым и неожиданным связанным данным?
4 ответа
Думаю, мой короткий ответ будет "не надо". Я немного седая борода, и сделал много отображения XML данных в реляционных базах данных. Если вы все-таки решите использовать такую базу данных, вам придется постоянно проверять свои данные. Вам также понадобится очень строгая дисциплина, чтобы избежать использования баз данных с небольшим количеством общих черт. Здесь помогает использование схемы, поскольку большинство XML-схем объектно-ориентированы и, следовательно, расширяемы, что снижает необходимость в анализе, чтобы не создавать похожие данные с разными именами, что заставит любого, кто имеет доступ к вашей базе данных, думать о вас дурными мыслями.
По моему личному опыту, если вы делаете те вещи, в которых есть смысл в сетевой базе данных, то вперед. Если нет, то вы теряете все остальные вещи, которые могут делать реляционные базы данных, такие как проверка целостности, транзакции и установка выбора. Однако, поскольку большинство людей все равно используют реляционную базу данных в качестве объектного хранилища, я думаю, что суть спорная.
Что касается того, как получить доступ к этим данным, просто поместите их в Хэшбол (Hashtable). Серьезно. Если нигде нет схемы, то вы никогда не узнаете, что там. Если у вас есть схема, вы можете использовать ее для генерации объектов доступа, но вы получите небольшой выигрыш, так как потеряете всю гибкость базового хранилища и одновременно получите негибкость DAO (Data Access Object).
Например, если у вас есть Hashtable, получить значения из парсера XML часто довольно просто. Вы определяете типы хранилищ, которые будете использовать, затем идете по дереву XML и помещаете значения в типы хранилищ, сохраняя их в Hashtable или List соответственно. Однако, если вы используете DAO, то в конечном итоге вы не сможете тривиально расширить объект данных, что является одной из сильных сторон XML, и вам придется создавать геттеры и сеттеры для объектов, которые делают
public void setter(Element e) throws NoSuchElementException {
try {
this.Name = e.getChild("Name").getValue();
} catch (Exception ex) {
throw new NoSuchElementException("Element not found for Name: "+ex.getMessage());
}
}
За исключением, конечно, того, что вам придется делать это для каждого отдельного значения на этом уровне схемы, включая загрузчики и определения для подуровней. И, конечно же, вы получите гораздо больший беспорядок, если будете использовать более быстрые парсеры, которые используют обратные вызовы, так как теперь вы должны отслеживать, в каком объекте вы находитесь, когда вы создаете результирующее дерево.
Я сделал все это, хотя обычно я создаю валидатор, затем адаптер, который обеспечивает соответствие между XML и классом данных, затем примирительный процесс, чтобы примирить его с базой данных. Однако почти весь код в итоге генерируется. Если у вас есть DTD, вы можете сгенерировать большую часть Java кода для доступа к нему, и сделать это с разумной производительностью
В конце концов, я просто буду хранить данные в свободной форме, в сети или иерархические данные как данные в свободной форме, в сети или иерархические данные
.У меня нет опыта работы со схемой без БД в сочетании с ООП, у меня есть год опыта работы со схемой без БД и скриптинга. Судя по моему опыту, это может быть весьма полезным. БД, которую я использовал, также была распечатана (все произвольные строки). Это дает следующие преимущества:
- вам не нужно заботиться о структуре БД. Если вам нужно что-то хранить, вы просто сохраняете это. И вам не нужно заботиться о типах данных, которые подходят к языку сценариев
- вы можете легко добавлять отладочную информацию к "объектам" при необходимости, не имея пустых столбцов для большинства строк таблицы. Это позволяет вам даже хранить огромные куски данных там, где это необходимо,
- вам не нужно заботиться об обновлениях структуры БД. Вы просто записываете новые данные, которые поставляются с новой версией программного обеспечения, в базу данных. Таким образом, вам не нужен администратор для обновления структуры таблицы и преобразования старых данных. Просто это происходит на лету
- если ключ для ваших пар ключ-значение имеет осмысленное имя, вам не нужно много документации для ваших данных
Так что в моем случае схема без БД вместе со сценарием была очень полезна и имела огромный успех
Когда вы думаете об использовании объектов для схемы без БД, я бы попытался сохранить свободу, сохраняя объекты в хэш-таблице. Это дало бы вам свободу доступа ко всем парам ключ-значение - неважно, какой "объект" вы выбрали. Это также дало бы вам свободу добавлять новые значения ключей по мере необходимости.
Если ваши объекты (как в RSS-ленте) имеют хорошо определенную базу, имеет смысл придумать базовые объекты, которые инкапсулируют хорошо определенную базу, но также имеют какую-то хэш-карту для вашей свободы.
Как только вы обнаружите, что все больше и больше пар значений ключей оказываются "стандартными", просто обновите вашу объектную модель, чтобы инкапсулировать их - ваша программа будет эволюционировать в правильную структуру данных. Может быть, даже имеет смысл перенести часть данных в традиционную RMDBS позже.
Не переусердствуйте с инженерами - реализуйте возможности, когда это необходимо...
.Я бы сказал, что лучшая практика для безсхемного XML-файла - это создание схемы для него!
Иметь схему - не особенно приятно. Это значит, что нельзя каким-либо образом проверить файл, кроме как определить, является ли он хорошо сформированным XML или нет.
Не имея никакой семантики к файлу, это кажется неправдоподобным. Потому что это означает, что вы не знаете, что вы должны, сделали или вложите в него. Если это так, то это звучит подозрительно, как решение проблемы.
Если у вас нет схемы, потому что вы еще не знаете языка схемы, посмотрите на DTD. Это очень просто. Вы можете выучить и освоить его примерно за час или два, если у вас есть утилита проверки или парсер проверки в вашем приложении.
Если проблема, которая мешает вам иметь схему, заключается в том, что ваши правила схемы, кажется, не подходят для типов файлов определения схемы, которые вы рассматривали до сих пор, то не стоит бояться этого.
Хотя DTD и даже XSD (XML Schema) файлы несколько негибки, есть и другие, более гибкие типы файлов схемы. Поверьте мне, они гораздо проще, чем XSD.
Взгляните на спецификацию файла схемы RNC (RELAX NG, компактный). Файлы RNC очень легко читать и записывать. Есть несколько XML-редакторов, которые их понимают. Есть утилиты, которые преобразуют туда-сюда между RELAX NG форматом (RNG или RNC) и другими форматами, такими как DTD и XSD.
Последний раз, когда я проверял, XHTML TR включал в себя ненормативный RNC-файл для помощи в его проверке, не говоря уже о его однозначном документировании. RELAX NG обладает для этого гибкостью, и вы можете действительно прочитать его, не будучи частью коллектива Боргов. В этом случае Borg не является эвфемизмом Microsoft.
Если вам нужно что-то еще более гибкое, чем RELAX NG, взгляните на Schematron. Это очень хороший, основанный на правилах язык проверки схем. Он не очень сложный. Как и эти другие языки схем, он тоже существует уже давно, является зрелым и признанным стандартом.
Даже у некоторых старших инженеров Microsoft были серьезные опасения по поводу XSD. Сложность очень высока, она оказывается неспособна выразить определённые не очень удобные схемы данных, она очень многословна, в ней смешиваются такие проблемы, как валидация и значения по умолчанию, и так далее. Что бы вы ни делали, это звучит не очень хорошо для непосредственной поддержки.
RDF мапперы, как и инструменты связывания XSD, хорошо подходят для сохраняющихся объектов, учитывая их классы на некоторых поддерживаемых языках программирования, таких как Java (например, с JAXB). Однако, не ясно, что у вас есть некоторые классы, которые вы хотите сохранить в первую очередь.
Есть некоторые семантические веб-технологии, такие как OWL и RDF, которые являются гибкими и очень динамичными.
Одним из инструментов, на который вы можете захотеть посмотреть, является Stanford's Protege. Он достаточно мощный и очень гибкий. В основном это семантическая веб-интерфейс и фреймворк. Последний написан на Java, так же как и инструмент. Однако, семантическая веб-схема и файлы данных, которые Protege создает и редактирует, могут быть использованы программами, написанными на любом языке. В таких файлах нет предубеждений по отношению к Java.
Кроме того, вы можете найти множество семантических web-схем с помощью Swoogle. Возможно, уже есть схема, которая подходит к любому вашему приложению.
В принципе, придумать файл схемы на одном из этих многих языков проверки схем не так уж и сложно, если вы знаете, что хотите поместить в файл XML-данных. Если вы понятия не имеете, то вряд ли программа или человек узнает, что с ней делать, когда прочитает ее. Если это так, то XML может быть не лучшим представлением для хранения данных. Я не уверен, что что-то будет.
Вместо этого, вы можете просто захотеть делать то, что вы делаете в общем, динамически набранном скриптовом языке, таком как Python или Ruby. LISP также можно использовать, если вы хотите, чтобы ваши программы могли не только иметь неограниченное количество форматов данных, но и сами себя модифицировать.
Другой вариант бессхемного хранения данных - язык логического программирования. Обычно они не имеют никаких схем. Вместо них есть онтология .
Два языка программирования, с которыми я много работал, использующих онтологии, это CLIPS и Prolog. Есть свободные, с открытым исходным кодом, кроссплатформенные, реализации обоих.
Взгляните на SWI-Prolog; быстрый, простой и мощный. В нем можно определить факты, а также правила, которые в основном синтезируют соответствующие факты, когда это необходимо. Вы извлекаете данные с помощью запросов. Пролог на самом деле был вдохновением для RDF, когда он был создан, насколько я помню, еще в 1990-х годах. Оригинальная документация RDF использовалась для частых ссылок на Пролог. Если вы хотите "обнаружить" или "проанализировать" или "найти" факты в своей онтологии, Пролог является очень хорошим языком для написания таких приложений. Он также удобен для разбора естественного языка.
CLIPS тоже хорош, если вы ищете решение проблем с фактами в своей онтологии. Он хорошо подходит для организации, поиска и устранения неисправностей и конфигурирования приложений.
Если схемы - не ваша стихия, то, возможно, онтология - ваша. Если нет, то, возможно, вам следует просто использовать динамически набранный язык сценариев и сохранять данные, хранящиеся в сложных объектах, используя карты и списки в файлы, используя их стандартные механизмы персистентности
.Используйте MongoDB или другие базы данных nosql. Также смотрите этот блог, Почему я думаю, что Mongo - это для баз данных, что такое Rails для Framework.
.