Лучшие практики для доступа к данным без схемы?
Я играю с RDF и, в частности, как получить доступ к информации, хранящейся в хранилище rdf. Огромным отличием от традиционной реляционной базы данных является отсутствие предопределенной схемы: в реляционной базе данных вы знаете, что в таблице есть эти столбцы, и вы можете технически сопоставить каждую строку с экземпляром класса. Класс имеет четко определенные методы и четко определенные атрибуты.
В системе без схемы вы не знаете, какие данные связаны с данной информацией. Это похоже на таблицу базы данных с произвольным и не предопределенным количеством столбцов, и каждая строка может содержать данные в любом количестве этих столбцов.
Как и в ObjectRelational Mappers, существуют Object RDF-преобразователи. RDFAlchemy и SuRF - те два, в которые я сейчас играю. По сути, они предоставляют вам объект Resource, методы и атрибуты которого предоставляются динамически. Это имеет смысл... однако, это не так просто. Во многих случаях вы предпочитаете иметь четко определенный интерфейс и иметь больший контроль над тем, что происходит, когда вы устанавливаете и получаете данные о вашем объекте модели. Наличие такого общего доступа в некотором смысле усложняет ситуацию.
Еще одна вещь (и самая важная), которую я отметил, заключается в том, что, даже если в общем случае ожидается, что данные без схемы будут предоставлять произвольную информацию о ресурсе, на практике вы более или менее знаете "классы информации", которые обычно бывают вместе. Конечно, вы не можете исключить наличие дополнительной информации, но это, в некоторых случаях, является исключением, а не нормой, хотя исключение достаточно разумно, чтобы быть слишком разрушительным для строгой схемы. В rdf-представлении статьи (например, как в каналах RSS/ATOM) вы знаете условия описанных вами ресурсов и можете сопоставить их с четко определенным объектом. Если вы предоставляете дополнительную информацию, вы можете определить расширенный объект (унаследованный от базового) для обеспечения доступа к расширенной информации. Таким образом, в некотором смысле вы имеете дело с данными без схемы с помощью "объектов, ориентированных на схему", которые вы можете расширить, когда хотите увидеть конкретную дополнительную информацию, которая вас интересует.
Мой вопрос относится к вашему опыту практического использования хранилища данных без схемы. Как они соотносятся с объектно-ориентированным миром, чтобы вы могли использовать его умело и не приближаясь слишком близко к "голому металлу" хранилища без схемы? (в терминах RelDB, без использования слишком большого количества SQL и непосредственного вмешательства в структуру таблицы)
Обречен ли доступ быть очень общим (например, "подключенные атрибуты" SuRF - это самый высокий, самый специализированный уровень, который вы можете иметь для доступа к своим данным), или наличие специализированных классов для конкретных согласованных удобных схем также является хорошим подходом, вводя однако риск увеличения числа классов для доступа к новым и неожиданным связанным данным?
4 ответа
Я предполагаю, что мой короткий ответ будет "не". Я немного серый и сделал много картографирования данных 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 для доступа к нему и делать это с разумной производительностью.
В конце концов, я просто сохранил бы произвольные, сетевые или иерархические данные как произвольные, сетевые или иерархические данные.
Я бы сказал, что для 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, которые являются гибкими и очень динамичными.
Одним из инструментов, на который вы, возможно, захотите взглянуть, является Стэнфордский протеже. Это довольно мощный и очень гибкий. Это в основном семантическая сеть IDE и фреймворк. Последний написан на Java, как и инструмент. Однако схема семантической сети и файлы данных, которые Protege создает и редактирует, могут использоваться программами, написанными на любом языке. В таких файлах нет смещения по отношению к Java.
Кроме того, вы можете найти множество семантических веб-схем с помощью Swoogle. Возможно, уже существует схема, которая подходит для любого приложения.
По сути, придумать файл схемы на одном из этих многих языков проверки схемы несложно, если вы знаете, что хотите поместить в свой файл данных XML. Если вы понятия не имеете, то вряд ли программа или человек узнают, что с ней делать, когда они ее прочитают. Если это так, XML может быть не лучшим представлением хранилища. Я не уверен, что что-нибудь будет.
Вместо этого вы можете просто захотеть делать то, что вы делаете, в универсальном, динамически типизированном языке сценариев, таком как Python или Ruby. LISP также можно использовать, если вы хотите, чтобы ваши программы могли не только иметь неограниченные форматы данных, но и иметь возможность изменять самих себя.
Другой вариант хранения данных без схемы - это язык логического программирования. Обычно они не имеют никакой схемы. Вместо этого у них есть онтология.
Два языка программирования, над которыми я много работал с онтологиями использования, - это CLIPS и Prolog. Доступны бесплатные кроссплатформенные реализации с открытым исходным кодом.
Посмотрите на SWI-Пролог; быстрый, простой и мощный. Вы можете определить факты в нем и правила, которые в основном синтезируют соответствующие факты, когда это необходимо. Вы извлекаете данные с помощью запросов. Пролог был источником вдохновения для RDF, когда он был создан еще в 1990-х годах, насколько я помню. Оригинальная документация RDF использовалась для частых ссылок на Prolog. Если вы хотите "обнаружить" или "проанализировать" или "найти" факты о фактах в вашей онтологии, Prolog - очень хороший язык для написания таких приложений. Это также удобно для анализа естественного языка.
Клипы тоже хороши, если вы хотите решить проблемы с фактами в вашей онтологии. Он хорошо подходит для организации, устранения неполадок и настройки приложений.
Если схемы не ваша вещь, возможно, онтологии. Если нет, то, возможно, вам следует просто использовать динамически типизированный язык сценариев и сохранять данные, хранящиеся в сложных объектах, используя карты и списки, в файлы, используя их стандартные механизмы сохранения.
Используйте MongoDB или другие базы данных nosql. Также см. Этот блог, почему я считаю Mongo для баз данных тем же, чем Rails для Framework.
У меня нет опыта работы со схемой без БД в сочетании с ООП, с опытом работы со схемой без БД и сценариями. По моему опыту, это может быть весьма полезно. БД, которую я использовал, также был нетипизирован (все произвольные строки). Это приводит к следующим преимуществам:
- Вам не нужно заботиться о структуре вашей БД. Если вам нужно что-то хранить, вы просто храните это. И вам не нужно заботиться о типах данных, которые соответствуют языку сценариев
- Вы можете легко добавлять отладочную информацию к "объектам", когда это необходимо, не имея пустых столбцов для большинства строк таблицы. Это позволяет вам даже хранить огромные порции данных, где это необходимо,
- вам не нужно заботиться об обновлениях структуры БД. Вы просто записываете новые данные, которые приходят с вашей новой версией программного обеспечения, в базу данных. Таким образом, вам не нужен администратор, чтобы обновить структуру таблицы и преобразовать ваши старые данные. Это просто происходит на лету
- если ключ для ваших пар ключ-значение имеет осмысленное имя, вам не нужно много документации для ваших данных
Так что в моем случае схема без БД вместе со сценариями была очень полезной и имела огромный успех.
Когда вы думаете об использовании объектов для схемы без БД, я стараюсь сохранить свободу, сохраняя объекты в хеш-таблице. Это даст вам свободу доступа ко всем парам ключ-значение - независимо от того, какой "объект" вы выбрали. Это также даст вам свободу добавлять новые значения ключей по мере необходимости.
Если ваши объекты (как в RSS-канале) имеют четко определенную базу, имеет смысл придумать базовые объекты, которые инкапсулируют четко определенную базу, но также имеют некоторую хэш-карту для вашей свободы.
Как только вы обнаружите, что все больше и больше пар ключ-значение оказываются "стандартными", просто обновите свою объектную модель, чтобы инкапсулировать их - ваше программное обеспечение разовьется в правильную структуру данных. Возможно, имеет смысл перенести некоторые данные в традиционную RMDBS позже.
Не переусердствуйте - используйте функции, когда это необходимо...