我正在研究RDF,特别是如何访问存储在rdf存储中的信息。与传统的关系型数据库相比,巨大的区别在于缺乏预定义的模式:在关系型数据库中,您知道表具有哪些列,并且可以从技术上将每行映射到类的实例。该类具有明确定义的方法和属性。
在无模式系统中,您不知道给定信息关联的数据是什么。这就像拥有一个带有任意数量未预定义列的数据库表,每行可以在任意数量的这些列中具有数据。
与对象关系映射器类似,还有对象RDF映射器。 RDFAlchemy和SuRF是我现在正在使用的两个。基本上,它们为您提供了一个资源对象,其方法和属性是动态提供的。这有点有道理...但是,这并不容易。在许多情况下,您更喜欢具有明确定义的接口,并且在设置和获取模型对象上的数据时更加控制。这种通用访问使事情变得困难,在某种意义上。
我注意到的另一件事(也是最重要的)是,即使在一般情况下,期望无模式数据提供关于资源的任意信息,但在实践中,您或多或少地知道“信息类别”倾向于在一起。当然,您不能排除附加信息的存在,但在某些情况下,这是例外,而不是规则,尽管异常足够敏感,以至于严格模式太具有破坏性。在文章的rdf表示(例如,在RSS / ATOM提要中)中,您知道所描述资源的术语,并且可以将它们映射到明确定义的对象。如果提供其他信息,则可以定义扩展对象(从基本对象继承),以提供对增强信息的访问器。因此,在某种意义上,您通过“面向模式的对象”来处理无模式数据,可以在需要查看特定附加信息时进行扩展。
我的问题与您在实际使用无模式数据存储方面的经验有关。它们如何映射到面向对象的世界,以便您可以熟练使用它们,而不会过于接近无模式存储的“裸金属”?(在RelDB术语中,不使用太多SQL并直接干涉表结构)
访问是否注定非常通用(例如,SuRF的“插入属性”是您可以访问数据的最高,最专业的级别),或者具有特定约定方便模式的专门类也是一种好方法,引入了访问新和意外关联数据的类繁殖的风险?
在无模式系统中,您不知道给定信息关联的数据是什么。这就像拥有一个带有任意数量未预定义列的数据库表,每行可以在任意数量的这些列中具有数据。
与对象关系映射器类似,还有对象RDF映射器。 RDFAlchemy和SuRF是我现在正在使用的两个。基本上,它们为您提供了一个资源对象,其方法和属性是动态提供的。这有点有道理...但是,这并不容易。在许多情况下,您更喜欢具有明确定义的接口,并且在设置和获取模型对象上的数据时更加控制。这种通用访问使事情变得困难,在某种意义上。
我注意到的另一件事(也是最重要的)是,即使在一般情况下,期望无模式数据提供关于资源的任意信息,但在实践中,您或多或少地知道“信息类别”倾向于在一起。当然,您不能排除附加信息的存在,但在某些情况下,这是例外,而不是规则,尽管异常足够敏感,以至于严格模式太具有破坏性。在文章的rdf表示(例如,在RSS / ATOM提要中)中,您知道所描述资源的术语,并且可以将它们映射到明确定义的对象。如果提供其他信息,则可以定义扩展对象(从基本对象继承),以提供对增强信息的访问器。因此,在某种意义上,您通过“面向模式的对象”来处理无模式数据,可以在需要查看特定附加信息时进行扩展。
我的问题与您在实际使用无模式数据存储方面的经验有关。它们如何映射到面向对象的世界,以便您可以熟练使用它们,而不会过于接近无模式存储的“裸金属”?(在RelDB术语中,不使用太多SQL并直接干涉表结构)
访问是否注定非常通用(例如,SuRF的“插入属性”是您可以访问数据的最高,最专业的级别),或者具有特定约定方便模式的专门类也是一种好方法,引入了访问新和意外关联数据的类繁殖的风险?