Лучшие практики для доступа к данным без схемы?

Question

Я играю с RDF и, в частности, как получить доступ к информации, хранящейся в хранилище rdf. Огромным отличием от традиционной реляционной базы данных является отсутствие предопределенной схемы: в реляционной базе данных вы знаете, что в таблице есть эти столбцы, и вы можете технически сопоставить каждую строку с экземпляром класса. Класс имеет четко определенные методы и четко определенные атрибуты.

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

Как и в ObjectRelational Mappers, существуют Object RDF-преобразователи. RDFAlchemy и SuRF - те два, в которые я сейчас играю. По сути, они предоставляют вам объект Resource, методы и атрибуты которого предоставляются динамически. Это имеет смысл ... однако, это не так просто. Во многих случаях вы предпочитаете иметь четко определенный интерфейс и иметь больший контроль над тем, что происходит, когда вы устанавливаете и получаете данные о вашем объекте модели. В некотором смысле наличие такого общего доступа усложняет ситуацию.

Еще одна вещь (и самая важная), которую я отметил, заключается в том, что, даже если в общая , ожидается, что данные без схемы предоставят произвольную информацию о ресурсе, на практике вы больше или меньше знают «классы информации», которые, как правило, вместе. Конечно, вы не можете исключить наличие дополнительной информации, но это, в некоторых случаях, является исключением, а не нормой, хотя исключение достаточно разумно, чтобы быть слишком разрушительным для строгой схемы. В rdf-представлении статьи (например, как в каналах RSS / ATOM) вы знаете условия описанных вами ресурсов и можете сопоставить их с четко определенным объектом. Если вы предоставляете дополнительную информацию, вы можете определить расширенный объект (унаследованный от базового) для предоставления доступа к расширенной информации. Таким образом, в некотором смысле вы имеете дело с данными без схемы с помощью «объектов, ориентированных на схему», которые вы можете расширить , когда вы хотите увидеть конкретную дополнительную информацию, которая вас интересует.

Мой вопрос связан с вашим опытом практического использования хранилища данных без схемы. Как они соотносятся с объектно-ориентированным миром, чтобы вы могли использовать его умело и не приближаясь слишком близко к «голому металлу» хранилища без схемы? (в терминах RelDB, без использования слишком большого количества SQL и непосредственного использования структуры таблицы)

Является ли доступ обреченным на очень общий характер (например, «подключаемые атрибуты» SuRF - это самый высокий, самый специализированный уровень, который вы можете иметь для доступа к своим данным), или наличие специализированных классов для конкретных согласованных удобных схем также является хорошим подходом Вводя, однако, риск увеличения числа классов для доступа к новым и неожиданным связанным данным?

Answer 1

Полагаю, мой короткий ответ будет "не надо". Я немного серый и сделал много картографирования данных XML в реляционных базах данных. Если вы решите использовать такую ​​базу данных, вам придется постоянно проверять свои данные. Вам также понадобится очень строгая дисциплина, чтобы избежать наличия общих баз данных. Здесь помогает использование схемы, так как большинство XML-схем являются объектно-ориентированными и, следовательно, расширяемыми, что избавляет от необходимости анализа для создания похожих данных с разными именами, что заставит любого, кто имеет доступ к вашей базе данных, думать о вас дурно.

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

Что касается доступа к этим данным, просто поместите их в Hashtable. Шутки в сторону. Если нигде нет схемы, то вы никогда не узнаете, что там. Если у вас есть схема, вы можете использовать ее для генерации объектов доступа, но вы получаете небольшую выгоду, так как теряете всю гибкость базового хранилища и одновременно получаете негибкость DAO (объекта доступа к данным).

Например, если у вас есть 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 для доступа к нему и делать это с разумной производительностью.

В конце концов, я просто сохранил бы произвольные, сетевые или иерархические данные как произвольные, сетевые или иерархические данные.

Answer 2

Я бы сказал, что для XML-файла без схемы рекомендуется создать для него схему!

Отсутствие схемы не особенно приятно. Это означает, что вы не можете проверить файл каким-либо образом, кроме как определить, является ли он правильно сформированным XML или нет.

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

Если у вас нет схемы, потому что вы еще не знаете язык схемы, взгляните на DTD. Это очень просто. Вы можете изучить и освоить его примерно через час или два, если в вашем приложении есть утилита проверки или анализатор проверки.

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

Хотя файлы DTD и даже файлы XSD (XML-схемы) несколько негибки, существуют и другие более гибкие типы файлов схем. Поверьте, они намного проще, чем XSD.

Посмотрите спецификацию файла схемы RNC (RELAX NG, compact). Файлы 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, которые являются гибкими и очень динамичными.

Один инструмент, на который вы, возможно, захотите взглянуть, - это Protege Стэнфорда. Это довольно мощный и очень гибкий. Это в основном семантическая сеть IDE и фреймворк. Последний написан на Java, как и инструмент. Однако схема семантической сети и файлы данных, которые Protege создает и редактирует, могут использоваться программами, написанными на любом языке. В таких файлах нет смещения по отношению к Java.

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

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

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

Другой вариант хранения данных без схемы - это язык логического программирования. Обычно они не имеют никакой схемы. Вместо этого они имеют онтологию .

Два языка программирования, с которыми я много работал, это онтологии CLIPS и Prolog. Доступны бесплатные кроссплатформенные реализации с открытым исходным кодом.

Взгляните на SWI-Prolog ; быстрый, простой и мощный. Вы можете определить факты в нем и правила, которые в основном синтезируют соответствующие факты, когда это необходимо. Вы извлекаете данные с запросами. Пролог был источником вдохновения для RDF, когда он был создан еще в 1990-х годах, насколько я помню. Оригинальная документация RDF использовалась для частых ссылок на Пролог. Если вы хотите «обнаружить», «проанализировать» или «найти» факты о фактах в вашей онтологии, Prolog - очень хороший язык для написания таких приложений. Это также удобно для анализа естественного языка.

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

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

Answer 3

Используйте MongoDB или другие базы данных nosql. Также смотрите этот блог на Почему я считаю Mongo для баз данных тем же, чем Rails для Framework .

Answer 4

У меня нет опыта работы со схемой без БД в сочетании с ООП, а у меня есть год опыта работы со схемой без БД и сценариями. По моему опыту, это может быть весьма полезно. БД, которую я использовал, также был нетипизирован (все произвольные строки). Это приводит к следующим преимуществам:

• вам не нужно заботиться о структуре вашей БД. Если вам нужно что-то хранить, вы просто храните это. И вам не нужно заботиться о типах данных, которые соответствуют языку сценариев
• вы можете легко добавлять отладочную информацию к "объектам", когда это необходимо, не имея пустых столбцов для большинства строк таблицы. Это позволяет вам даже хранить огромные порции данных, где это необходимо,
• вам не нужно заботиться об обновлениях структуры БД. Вы просто записываете новые данные, которые приходят с вашей новой версией программного обеспечения, в базу данных. Таким образом, вам не нужен администратор для обновления структуры таблицы и преобразования ваших старых данных. Это просто происходит на лету
• если ключ для ваших пар ключ-значение имеет осмысленное имя, вам не нужно много документации для ваших данных

Так что в моем случае БД без схемы вместе со сценариями была очень полезной и имела огромный успех.

Когда вы думаете об использовании объектов для БД без схемы, я стараюсь сохранить свободу, сохраняя объекты в хеш-таблице. Это даст вам свободу доступа ко всем парам ключ-значение - независимо от того, какой «объект» вы выбрали. Это также даст вам свободу добавлять новые значения ключей по мере необходимости.

Если ваши объекты (как в RSS-канале) имеют четко определенную базу, имеет смысл создать базовые объекты, которые инкапсулируют четко определенную базу, но также имеют некоторую хэш-карту для вашей свободы.

Как только вы обнаружите, что все больше и больше пар ключ-значение оказываются "стандартными", просто обновите вашу объектную модель, чтобы инкапсулировать их - ваше программное обеспечение превратится в правильную структуру данных. Возможно, имеет смысл даже перенести некоторые данные в традиционную RMDBS позже.

Не переусердствуйте - используйте функции, когда это необходимо ...