dbTalk Databases Forums  

Database design - storing metadata of various types

comp.databases comp.databases


Discuss Database design - storing metadata of various types in the comp.databases forum.



Reply
 
Thread Tools Display Modes
  #11  
Old   
Neo
 
Posts: n/a

Default Re: Database design - storing metadata of various types - 12-21-2006 , 02:52 PM






Quote:
Note, encoding data as EAVs by itself is fine.
It works well in a db like dbd and non-dbs such as Prolog.

As you point out Prolog is not a database. (Last I checked it was a
programming language. Why should you bring it up? It's like comparing
apples to race cars.)
While Prolog is primarily a programming language, it is also a database
according my definition which includes anything that can store and
recall things. If you have a narrower/refined definition which excludes
Prolog, that is fine.

Quote:
If you have a non-EAV schema for OP's requirements, please post it.
ONE: I do not know what attributes he desires.
It is possible, the OP is in a similar situation. If he is, he may want
to employ EAV-type design to handle attributes that are unknown at
design-time, while keeping in mind the reduced performance, SQL &
constraint support and increased code/complexity.

Quote:
TWO: before issuing such a challenge, why don't you post one that fits
his needs. (you can't because of ONE, but I know you'll keep posting
your obscure examples anyway.)
I also do not know his exact requires. But if his requirements are to
store things with widely varied attributes and/or attributes that will
not be known at design time, then I might suggest:

tMedia (mID, name)
tAttrib (aID, name)
tValue (vID, valAsTxt, valType)
tEAV (mID, aID, vID)

For a similar example see www.dbfordummies.com/example/ex111.asp

Quote:
EAVs are a poor choice for almost any data storage system.
[silly example deleted]
Let us verify your assertion. Please replicate the dbd example with a
non-EAV RMDB solution.



Reply With Quote
  #12  
Old   
Ed Prochak
 
Posts: n/a

Default Re: Database design - storing metadata of various types - 12-22-2006 , 09:53 AM







Neo wrote:
Quote:
Note, encoding data as EAVs by itself is fine.
It works well in a db like dbd and non-dbs such as Prolog.

As you point out Prolog is not a database. (Last I checked it was a
programming language. Why should you bring it up? It's like comparing
apples to race cars.)

While Prolog is primarily a programming language, it is also a database
according my definition which includes anything that can store and
recall things. If you have a narrower/refined definition which excludes
Prolog, that is fine.

If you have a non-EAV schema for OP's requirements, please post it.
ONE: I do not know what attributes he desires.

It is possible, the OP is in a similar situation. If he is, he may want
to employ EAV-type design to handle attributes that are unknown at
design-time, while keeping in mind the reduced performance, SQL &
constraint support and increased code/complexity.
The OP knows some basics of what he plans to store. It apparently will
be a library for a media collection. So there are some initial entities
that he knows will exist (books, tapes, CDROM, DVD, jump drives,
journals, comic books, trading cards,...). So there is no reason for
him to put ALL data into the EAV table. So similar to pseudokeys, he
should avoid EAV as much as possible.

Quote:
TWO: before issuing such a challenge, why don't you post one that fits
his needs. (you can't because of ONE, but I know you'll keep posting
your obscure examples anyway.)

I also do not know his exact requires. But if his requirements are to
store things with widely varied attributes and/or attributes that will
not be known at design time, then I might suggest:

tMedia (mID, name)
tAttrib (aID, name)
tValue (vID, valAsTxt, valType)
tEAV (mID, aID, vID)

For a similar example see www.dbfordummies.com/example/ex111.asp

EAVs are a poor choice for almost any data storage system.
[silly example deleted]

Let us verify your assertion. Please replicate the dbd example with a
non-EAV RMDB solution.
I won't replicate your mindless EAV, but I'll put out some examples.

here's one that deals with online media (email, Instant Messages,
blogs)
https://dspace.mit.edu/bitstream/172...1/56016821.pdf
he even reviews different DB models, including Object DB, and concludes
Relational is the way to go.

A link for digital library for music is here:
http://www.dml.indiana.edu/pdf/minib...n-jcdl2002.pdf
.. It provides a nice ERD for the OP to start building his system. It
should not be too hard to expand the model for other things like
movies/videos. Once you begin to store binary data, one type is the
same as another.

I'm sure the OP could find similar references, though it seems to take
a little tuning in GOOGLE (there are a lot of links that come back).

The point is: there is no reason for him to put everythingin an EAV.
Such a design will merely lead eventually to wailing and knashing of
teeth.
Ed



Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.