Name value pair (EAV) model

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss content posted by Teshome Asfaw » Name value pair (EAV) model

42 posts, Page 1 of 5

1 2 3 4 5 »»»

Name value pair (EAV) model

Rate Topic

Display Mode

Topic Options

Author

Message

Teshome-283915

Posted Sunday, March 23, 2008 10:08 PM

Grasshopper

Group: General Forum Members
Last Login: 2 days ago @ 4:24 AM
Points: 24, Visits: 374

Comments posted to this topic are about the item Name value pair (EAV) model

Post #473346

Anipaul

Posted Monday, March 24, 2008 2:51 AM

SSCarpal Tunnel

Group: General Forum Members
Last Login: Wednesday, May 22, 2013 1:35 AM
Points: 4,789, Visits: 1,336

Part I of the article is good but I am more eager for its Part II. I will request him to write fast the Part II. :)

Post #473379

Teshome-283915

Posted Monday, March 24, 2008 5:19 AM

Grasshopper

Group: General Forum Members
Last Login: 2 days ago @ 4:24 AM
Points: 24, Visits: 374

I am nearly there and will try to get in as soon as I can.

regards

Teshome

Post #473404

SuperDBA-207096

Posted Monday, March 24, 2008 5:27 AM

UDP Broadcaster

Group: General Forum Members
Last Login: Wednesday, January 02, 2013 12:15 PM
Points: 1,443, Visits: 711

Looking forward to part 2.

I inherited a DB like this - using name value pairs. Biggest drawback: Performance!

Post #473407

Teshome-283915

Posted Monday, March 24, 2008 5:40 AM

Grasshopper

Group: General Forum Members
Last Login: 2 days ago @ 4:24 AM
Points: 24, Visits: 374

Hi mark,

I am also looking forward to comments on part II of the article.

Thanks

Teshome

Post #473413

Jeff Moden

Posted Monday, March 24, 2008 6:03 AM

SSC-Dedicated

Group: General Forum Members
Last Login: Today @ 6:25 PM
Points: 32,930, Visits: 26,819

Part I is a good (possibly too brief) introduction to EAV's ;) Like the other's I'm looking forward to Part II.

--Jeff Moden

"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Post #473422

Cade Roux

Posted Monday, March 24, 2008 6:52 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, January 23, 2013 9:10 PM
Points: 105, Visits: 481

EAV has its place. Regarding performance, indexes and efficient code can usually mitigate that.

I'd like to see more discussion about type-safety and whether there are any tricks for that which I haven't seen.

Post #473433

peterhe

Posted Monday, March 24, 2008 9:09 AM

Mr or Mrs. 500

Group: General Forum Members
Last Login: Wednesday, February 20, 2013 10:51 AM
Points: 531, Visits: 416

SQL Server 2008 has better support for EAV by sparse columns/columns set

Post #473512

JRoughgarden

Posted Monday, March 24, 2008 10:40 AM

SSC Rookie

Group: General Forum Members
Last Login: Tuesday, January 29, 2013 6:07 PM
Points: 36, Visits: 167

I am currently designing a DB that employs this name value pair approach to store arbitrary sets of attributes to be associated to a variety of entities. I am concerned about performance. but generally deal with with performance problems after they arise.

The product and marketing folks love the concept because it lets them promise anything to customers. They can avoid writing specs and get flexibility at the expense of performance, which is not their problem anyway. Rolleyes

One alternative seems to be entity tables with an ever-increasing list of nullable fields associated with the entities of interest, the union of all attributes. I'm not very keen on this approach either. Another approach is to have a master entity table with 1-1 subordinate sub-tables for the various entity types, but this also makes for a complicated schema.

I am setting the data type for the attribute values to be nvarchar, for localization. Three-character prefixes on the attribute names indicate the actual type of the value, e.g. strName, datEffective, smnPrice, etc. C# programmers are comfortable with the .Parse(string) functions and can retrieve the strongly typed actual value with these methods.

I hope this all works out, but any words of warning are much appreciated.

Jeff Roughgarden, MCDBA, MCSD

Post #473589

Cade Roux

Posted Monday, March 24, 2008 10:58 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, January 23, 2013 9:10 PM
Points: 105, Visits: 481

Since you are dealing with internationalization already, what form are you using for numeric data in the fields?:

9,999.99
9.999,99

Your C# code will need to parse with a specific locale, otherwise users changing their regional settings will result in differing formats.

This is a fundamental flaw in EAV models - interpretation of what is, effectively, free-form data that the database cannot help you enforce the rules on.

Even when it is only used for configuration, if the value is used as a threshold option like "Minimum Shipping Charge", it could come into calculations.

EAV is useful - it's great for options and configurations.

Not so good for the "designing a database within a database" idea.

But this problem of type-safety and validation has not yet been addressed to my satisfaction in any architecture I've seen.

Post #473597

« Prev Topic | Next Topic »

42 posts, Page 1 of 5

1 2 3 4 5 »»»

Permissions