Рекомендации по доступу к данным без схемы?

Question

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

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

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

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

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

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

Answer 1

Я предполагаю, что мой короткий ответ будет «не надо». Я немного сердитый, и сделал много картографических данных 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 для доступа к нему и сделать это с разумной производительностью.

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

Answer 2

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

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

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

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

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

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

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

Answer 3

Я бы сказал, лучшая практика для схемы менее файла XML является создание схемы для этого!

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

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

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

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

Хотя файлы DTD и даже XSD (XML Schema) несколько негибкие, существуют и другие более гибкие типы файлов схем. Поверьте мне, они намного проще, чем 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 от Stanford. Он достаточно мощный и очень гибкий. Это в основном семантическая веб-среда и среда. Последний написан на Java, как и инструмент. Тем не менее, создание семантической веб-схемы и файлов данных Protege создает и редактирование может использоваться программами, написанными на любом языке. В таких файлах нет предубеждений по отношению к Java.

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

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

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

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

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

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

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

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

Answer 4

Используйте MongoDB или другие базы данных nosql. Также см. Этот блог, Why I think Mongo is to Databases what Rails was to Framework.