Talk:Entity–attribute–value model

message: Maps very poorly to the relational model,
: The primary objective of the schema is to map "real life" concepts (i.e. heterogenous sparsely populated attributes; what you'd find in a patient's chart) instead of coercing "real life" into a relational model. You are still able to leverage relational concepts because of the methods you need to use to pivot, join, as well as perform localized normalization. Cowbert (talk) 01:54, 2 May 2008 (UTC)
replies: text: That is why in production you spin off EAV tables based on data types. EAV/CR directly addresses this issue: either the class table or the attribute table (if you are not using classes) stores metadata about which EAV table has all of those attribute's values. So you'd have an EAV_int, EAV_real, EAV_char, EAV_date etc. tables. When you enumerate the attribute for the entity, your business logic queries this metadata to determine which eav table to query for the value (example, patient_hemoglobin has a metadata column of 'eav_table' pointing to eav_real). Also, the constraints are now primarily metadata driven, instead of defined in the schema itself - again the primary goal is avoid having to coerce a certain representational system into a strict relational schema, where as the arguments that seem to be made are that "we must stick with relational schema" even though the whole point of the exercise is that a column-moduled schema poorly supports large and/or dynamic numbers of sparsely populated attributes (I can do a SELECT attribid, value FROM eavtable where entityid = foo vs. tossing all the null fields if I have a table where the attributes are column modeled [or worse, multiple tables of tons of sparse columns each that I'm going to have to index]). Finally, it has been admitted that the main difficulty more or less lies with attribute-centric queries (i.e. I *do* want to know every patient who is running a fever today, which brings up the necessity to pivot the attribute over into a columnar model or do some self-joins)) Cowbert (talk) 01:54, 2 May 2008 (UTC)

text: This is how the normalized eav schema of the above would look like:
 
 table test_events {<BR>
 eventid integer primary key,<BR>
 patientid integer foreign key references patient_table(patientid),<BR>
 timestamp date<BR>
 }<BR>
 <BR>
 test_metadata {<BR>
 testid int pkey,<BR>
 test_type varchar(),<BR>
 test_datatype int fkey references eav_types,<BR>
 test_unit_of_measure varchar()<BR>
 }<BR>
 <BR>
 eav_types {<BR>
 datatype int pkey,<BR>
 eav_table_name varchar()<BR>
 }<BR>
 <BR>
 patient_table {<BR>
 patientid int pkey,<BR>
 first_name varchar,<BR>
 last_name varchar,<BR>
 dob date<BR>
 ....<BR>
 }<BR>
 <BR>
 eav_real {<BR>
 eventid int fkey references test_events(eventid),<BR>
 testid int fkey references test_metatdata(testid),<BR>
 value real<BR>
 }<BR>
 <BR>
 ok. So now for the data/meta:<BR>
 <BR>
 patient_table VALUES { patientid = 1, first_name =... } <BR> 
 patient_event { eventid = 1, patientid = 1, date = 1/5/1998 }
 patient_event { eventid = 2, patientid = 1, date = 1/5/1998 }<BR><BR>
 test_metadata { testid = 1, test_type = 'hemoglobin', test_datatype = 1, test_unit_of_measure = 'g/dL'}
 test_metadata { testid = 2, test_type = 'potassium', test_datatype = 1, test_unit_of_measure = 'meq/L'}<BR><BR>
 eav_types { datatype = 1, eav_table_name = 'eav_real'}<BR><BR>
 eav_real { eventid = 1, testid = 1, value = 12.5 }
 eav_real { eventid = 2, testid = 2, value = 4.9 }<BR><BR> Cowbert (talk) 01:54, 2 May 2008 (UTC)
thread_title:  How about the Drawbacks? 

message: Seem like good points, but should be written in 3rd person, and should be sourced!  —Dfass 05:48, 24 December 2006 (UTC)
replies: text: I agree.  It is self-referential (referring to a previous version of the same article) in a way that is inappropriate.  It also seems that many of the points are already discussed in other sections, and the information in this section could be integrated there.  Nimrand 21:04, 1 June 2007 (UTC)
replies: text:  Just wanted to pop in and agree with the disappointment /w the Downsides section. It feels abundantly unprofessional and not up to the calibre I would normally expect from coverage of this topic from Wikipedia. More specifically, its placement, wording, and lack of sourcing make it sound like regressive sniping. Write some published papers on this and then cite it, until then (IMO) it shouldn't even be here...
The drawback number 2 (scalability for large datasets) can be greatly improved by using 2 queries for retrieving the data.
* 1st is for filtering and sorting the records, here you would self join ONLY attributes that are used in filters and order by. Ordered result of this query creates empty array with placeholders for entities. 
* 2nd is regular SELECT (or UNION when attributes are splited to few tables by type) that is filtered by entity id, which were received from 1st query. Result from this query is being fetched into array created by 1st query, which makes the result correctly sorted.
I've removed the downsides section entirely for now.  The article needs a downsides section to be sure, but the one it had was written in a personal/opinionated and unprofessional manner.  I think it's better to leave it out until someone can rewrite it without original research.--Fyedernoggersnodden (talk) 01:36, 22 March 2010 (UTC)
thread_title:  Downsides 

message: Rename to Entity-Attribute-Value model.  Proper nouns in this context, always capitalised. Andy Dingley (talk) 18:32, 25 July 2008 (UTC)
replies: text: I agree.  A simple Google search for entity attribute value will return items in which all three are capitalized. 76.120.35.164 (talk) 06:40, 2 September 2008 (UTC)
thread_title:  rename 

message: This article seems awfully biased towards specific domain (medicine) and specific works/people.
This article should be split in two: one on EAV modeling generally and another on EAV in medicine. It should also reference the newer variable schema NoSQL solutions (e.g. MongoDB and Solr) that address this problem also.  — Preceding unsigned comment added by Jroughgarden (talk • contribs) 21:50, 3 November 2011 (UTC)
replies: text: Because the first commercial application of it was in that domain and is the primary model used for data requirements within that domain. Feel free to talk about it in a non-medical domain with real examples if you have any (AFAIK, I have not seen EAV papers on or implementations for GIS or operational management domains "out in the field"; many domains now directly use ORM-based strategies and completely abstract out the schema entirely...) Cowbert (talk) 13:06, 15 October 2009 (UTC)
replies: text:  The Magento e-commerce system would be a good source of non-medical examples.  It uses a very EAV to store very complex and variable data.  —Preceding unsigned comment added by 158.158.240.230 (talk) 14:06, 19 October 2009 (UTC)

text:  The article appears to examine one implementation of EAV systems, and point out its flaws. The Large Record and repeating group models used in many modern Model 204 implementations removes requirement for large numbers of joins and allows for a very efficent method to record large datasets of time related data, requiring one group instance (only to house the actually changing data) instead of a complete, separately related table entry for each new datum. This results in a net reduction in the number of joins required to retrieve data.  —Preceding unsigned comment added by 115.187.253.93 (talk) 13:49, 7 March 2010 (UTC)
thread_title:  Biased 

message: I taggged this as "POV" because the following two phrases just don't belong in a serious discussion of technical concepts, but express a particular author/editor's point of view, and clearly fail the "WP:SOAP" test:
Metadata is so important to the operation of a production EAV system that in its absence, one is essentially trying to drive a car without brakes or a steering wheel.
The correctness of the metadata contents, in terms of the intended system behavior, is critical enough that the contents constitute the system's "crown jewels". 
TML (talk) 06:40, 26 March 2010 (UTC)
thread_title:  POV / Metaphor 

message: What disease is the example table of symptoms describing? :D 121.221.35.11 (talk) 11:39, 16 December 2010 (UTC)
thread_title:  Alright, I'm curious. 

message: I've read about "vertical tables" for example at 
http://www.developer.com/db/article.php/3736011/Using-Vertical-and-Horizontal-Table-Structures-in-Oracle.htm
which looks to me the same as EAV.
If they are in fact the same thing, maybe that should be mentioned in the article... I tried searching wikipedia to learn more about "vertical tables" and didn't find anything, but some googling made me think that EAV might be related or the same.  — Preceding unsigned comment added by Slinkp (talk • contribs) 18:20, 12 January 2011 (UTC)
thread_title:  Is EAV the same as "vertical table"? 

message: This article discusses relationships between different tables and comparisons between differing approaches.   It would benefit enormously with the inclusion of diagrams, even if hand-drawn. FreeFlow99 (talk) 15:52, 24 September 2013 (UTC)
thread_title:  Diagrams 

message: An informal but involved discussion on the proposed "Dynamic Relational" specification can be found at
http://c2.com/cgi/wiki?DynamicRelational
The "short" description is that tables can be conceptually modeled as a bunch of XML statements such as:
<employee lastname="Smith" firstname="John" salary=55000/>
<employee lastname="Adams" firstname="Lisa" middlename="Lee" salary=78100/>
<employee lastname="Bates" firstname="Gill" salary=30000/>
The implementation doesn't have to actually be XML, just resemble it (plus an automatic unique row identifier, not shown). It could be implemented with an Entry/Attribute/Value table(s) "under the hood". 
The above is a section from an example "employee" table. All attributes (columns) are optional unless an explicit requirement is issued to require such. Type validation can also optionally be added this way. This allows a table to incremental grow more rigid, closer to a regular RDBMS table. With some minor adjustments, SQL or a variation could the query language to make it familiar to users. One can "create" a column (attribute) simply by including it in an INSERT or UPDATE statement (unless declared forbidden for a given table). --146.233.255.212 (talk) 22:51, 22 August 2016 (UTC)
thread_title:  Dynamic Relational (A Similar Concept) 

message: Hello fellow Wikipedians,
I have just modified  on Entity–attribute–value model. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20111020035056/http://www.gnu.org:80/software/emacs/elisp/html_node/Association-Lists.html to https://www.gnu.org/software/emacs/elisp/html_node/Association-Lists.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 21:01, 24 December 2016 (UTC)
thread_title:  External links modified 

message: I have to say, this article is a bit of a mess, consisting of a lot of unconnected sections that are partly redundant. I tried to restructure the article by moving some sections around, but I think it'd help if it was cleaned up more thoroughly. Slhck (talk) 14:31, 25 April 2019 (UTC)
replies: text: Though I agree, at least someone did it and it's somewhat comprehensible to me so let's at least acknowledge that. A few diagrams might help though. 92.2.118.221 (talk) 09:44, 21 October 2021 (UTC)
thread_title:  Messy article 

message: > and the engine has components such as cylinders
''
i suggest re-phrasing this, because, obviously, not all engines necessarily 'have' cylinders. Previously Used Coffins (talk) 10:17, 17 July 2023 (UTC)
thread_title:  suggest a minor change 

message: The article refers to Google App Engine as though it were a database, but that is not correct. Google does offer a number of databases in their cloud platform. Any idea which DB the author intended to reference? Mrusso-wiki (talk) 18:47, 11 October 2023 (UTC)
thread_title:  Google App Engine is not a data store 

message: Pinned pages, reoccurring changes too factory settings internal properties changes made too certification. Using work done on actual engine (truck)( Sea horse) all too use Target change device digital integrations. Mobile cell wireless needs too get restored back too factory,  source coxbox  too interrupt paid services wifi internet. Same interrupt dta internet exhausting my UNLIMITED (DATA )SERVICE. BY( WORK )CHANGED MANIFOLD TOO HEADERS MUFFLER (EXHAUST) TOO GLASS( PAC) REALLY REALLY  — Preceding unsigned comment added by 2600:8807:CC0:EE30:31E9:9BA9:427B:5349 (talk) 13:53, 24 March 2024 (UTC)
thread_title:  recurring changes unknown too device