那么最初我考虑使用 EAV 时,我应该使用什么 RDF 数据库来处理产品属性情况呢?
我有一个类似的问题,如如何为多种产品设计一个产品表,其中每种产品都有许多参数
我现在确信使用 RDF。只是因为 Bill Karwin 在回答 上述问题
但我已经在mysql中有一个数据库并且代码在 php 中。
1)那么我应该使用什么RDF数据库?
2)我是否结合该方法?这意味着我在 mysql 数据库中有一个类表继承,而在 RDF 中有奇怪的产品属性?我认为我不应该将所有内容都转移到 RDF 数据库,因为它只是产品以及各种可能的属性和值,这给我带来了问题。
3) 我应该看哪些 php 资源、文章可以帮助我更好地创建这个?
4)如果有更多文章或资源能够帮助我在上述挑战的背景下更好地理解 RDF,即构建能够更好地容纳各种产品属性和价值的东西,我将不胜感激。当我对正在发生的事情有概念性的了解时,我往往会工作得更好。
请记住,我对此完全是新手,我对编程和数据库的了解充其量只是平均水平。
i have a similar issue as espoused in How to design a product table for many kinds of product where each product has many parameters
i am convinced to use RDF now. only because of one of the comments made by Bill Karwin in the answer to the above issue
but i already have a database in mysql and the code is in php.
1) So what RDF database should I use?
2) do i combine the approach? meaning i have a class table inheritance in the mysql database and just the weird product attributes in the RDF? I dont think i should move everything to a RDF database since it is only just products and the wide array of possible attributes and value that is giving me the problem.
3) what php resources, articles should i look at that will help me better in the creation of this?
4) more articles or resources that helps me to better understand RDF in the context of the above challenge of building something that will better hold all sorts of products' attributes and values will be greatly appreciated. i tend to work better when i have a conceptual understanding of what is going on.
Do bear in mind i am a complete novice to this and my knowledge of programming and database is average at best.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
好的,RDF 的主要好处之一是全局身份,因此如果您在 RDBMS 模式中使用代理 id,那么您可以从单个序列分配代理 id。这将使您的模式的某些 RDF 扩展更加容易。
因此,在您的情况下,您将使用单个序列来表示架构中的产品和其他实体(可能是用户等)的 id。
您可能应该在标准化 RDBMS 表中保留基本字段,例如包含具有基数的字段的产品表0-1。
其他的您可以保留在另一个表中。
例如,
如果您还想以动态形式引用数据,您可以添加以下元表:
这里引用通过代理 id 引用架构中的另一个实体。
如果您想为另一个表(假设是用户)提供元数据,您可以添加下表:
我将其作为不同的答案,因为它是比我的第一个答案更具体的建议。
Ok, one of the main benefits of RDF is global identity, so if you use surrogate ids in your RDBMS schema, then you could assign the surrogate ids from a single sequence. This will make certain RDF extensions to your schema easier.
So in your case you would use a single sequence for the ids of products and other entities in your schema (maybe users etc.)
You should probably keep essential fields in normalized RDBMS tables, for example a products table with the fields which have a cardinality of 0-1.
The others you can keep in an additional table.
e.g. like this
If you want also reference data in dynamic form you can add the following meta table :
Here reference refers via the surrogate id to another entity in your schema.
And if you want to provide metadata for another table, let's say user, you can add the following table :
I put this as a different answer, because it is a more specific suggestion then my first answer.
1 & 3) 当您使用 PHP 和 MySQL 时,您最好的选择是 ARC 2 (尽管网站声明这是一个预览版本(这是您想要的版本)或 RAP 两者都允许基于数据库的存储,允许您将数据存储在 MySql
ARC 2 中,根据我的经验,ARC 2 似乎更受欢迎并且维护得更好
2) 取决于您现有的代码库需要更改多少如果您将所有内容都转移到 RDF,以及您对数据库中的现有数据执行什么类型的查询。使用 RDF 和 SPARQL 有些事情可能会更快,而有些事情可能会更慢。
1 & 3) As you're using PHP and MySQL you're best bet would be either ARC 2 (although the website states this is a preview release this is the release you want) or RAP both of which allow for database based storage allowing you to store your data in MySql
ARC 2 seems to be more popular and well maintained in my experience
2) Depends how much of your existing code base would have to change if you move everything to RDF and what kinds of queries you do with the existing data in your database. Some things may be quicker using RDF and SPARQL while some may be slower.
我没有将 RDF 与 PHP 一起使用,但一般来说,如果您在一个项目中使用两种持久性技术,那么结果可能比单独使用一种更复杂、更危险。
如果您继续使用 RDBMS 方法,您可以通过引入以下属性使其更像 RDF:
您不必使用 RDF 引擎来将数据保存为 RDF 可映射形式。
与 EAV 相比,RDF 是一种更具表现力的动态数据建模范式。
I haven't used RDF with PHP, but in general if you use two persistence technologies in one project then the result is probably more complex and risky than using one alone.
If you stay with the RDBMS approach you can make it more RDF like by introducing the following attributes :
You don't have to use an RDF engine to keep your data in RDF mappable form.
Compared to EAV RDF is a more expressive paradigm for dynamic data modeling.