SO what RDF database do i use for product attribute situation initially i thought about using EAV?

Question

Hi,

i have a similar issue as espoused in http://stackoverflow.com/questions/695752/product-table-many-kinds-of-product-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.

Answer 1

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.

Answer 2

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 :

• use a single sequence for all surrogate ids, this way you get unique identifiers, which is a requirement for RDF
• use base tables for mandatory properties and extension tables with subject + property + values columns for additional data

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.

Answer 3

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

create table product (
  product_id int primary key,
  // core data here
)

create table product_meta (
  product_id int,
  property_id int,
  value varchar(255)
)

create table properties (
  property_id  int primary key,
  namespace varchar(255),
  local_name varchar(255)
)

If you want also reference data in dynamic form you can add the following meta table :

create table product_meta_reference (
  product_id int,
  property_id int, 
  reference int
)

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 :

create table user_meta (
  user_id int,
  property_id int,
  value varchar(255)
)

I put this as a different answer, because it is a more specific suggestion then my first answer.