Home Forums Article Discussions Article Discussions by Author Discuss Content Posted by David Poole Antipathy for Entity Attribute Value data models RE: Antipathy for Entity Attribute Value data models

  • January 30, 2013 at 6:44 am

    #1582588

    BillyJack (1/29/2013)

    Jeff Moden (1/28/2013)

    Heh... wait a minute now. Are you saying that you work in an environment where developers can make physical table changes directly in the production environment without testing/etc and without going through a DBA? Or is that what you're trying to avoid with the use of EAVs?

    The point I am trying to make is that with an EAV model, you don't need to do any table maintenance in order to add new attributes. They are simply new rows of data added to the EAV tables

    Yep. I agree. I've been there. It does make such a thing wicked easy. And it's simple enough to pivot the data into a table-like result set when needed by using a bit of dynamic SQL.

    It is a bit wicked, though. How are you handling similar but different attribute names for the same thing? For example, in address related data, you might have an attribute for "Street Number". Not including the potential for phat phingering, I can think of at least 15 different ways that might be entered as an attribute name. Short of a huge list of possible attribute names and a "simto" search, I've not found a way to overcome that problem.

    --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.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)