Re: Mapping arbitrary number of attributes to DB

On 2006-10-25, Bob Badour wrote:

> You are begging the question.

I believe the problem is the cost of up front modeling. I claim that it is sometimes solved by postponing the effort while storing the data, which means that the data will not be fully structured in the meanwhile. EAV on top of an RDBMS is one means of storing such semistructured data. Hence, there is a limited justification for using EAV or some similarly less-than-relational data representation. How is this circular?

> A dbms will allow one to dump each file into a relation that directly
> reflects the structure of the file. That doesn't cost a whole lot in
> terms of designing, and it does accomplish exactly what you describe
> above.

Correct, but how precisely is that better than EAV? Suppose you've progressed far enough to know that your users are going to be needing trend reports on the sensor data that is present in field #1 of the files produced by instrument A and in a different form in field #2 of instrument type B. You can somehow tell the instruments apart (e.g. by one of the attribute values or by the set of attributes present) , you've added an attribute in your core data model and you've implemented functions to convert the raw data into a uniform representation. You now need to move the data into the real schema. Which representation do you think makes this easier, EAV or mass-of-relations, if you're using plain SQL on the one hand, or the best existing tools for the model on the other? Which model reacts better if one of the sensors is upgraded to produce a new field? What happens when one of the fields has substructure which needs to be preserved?

-- 
Sampo Syreeni, aka decoy - mailto:decoy_at_iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2