Re: Mapping arbitrary number of attributes to DB

On 2006-10-24, J M Davitt wrote:

> I'm surprised that the entity-attribute-value design hasn't been
> mentioned yet.

Maybe by name it hasn't, but the principle in implicit in Joshua's original design: E is {station_id, row_id}, A is {column_number} and V is {value}. Granted, the representation is only applied to the part of the schema that is expected to change rapidly and the result seems nicer than normal because in this case it just so happens that all of the attribute values are known to be floats. Still, if it walks like a chicken, and talks like one...

OTOH, to me storing data with an open ended and not completely understood structure as EAV doesn't seem too bad, as long as the data we're actually querying and transforming is lifted off it and put into an ordinary schema. (Which you can always do because as soon as you understand the data sufficiently well to utilize it in any way besides passing it through to somebody more knowledgeable than you, you'll already know enough to write the DDL.) The best thing would be if the DBMS had full support for this sort of thing -- e.g. you could import blobs of data, a partial structuring schema could be imposed on them at the physical level, suddenly the part of the data that was declared would become visible as first class relations, and the rest of it would remain accessible as binary or some semistructured representation like EAV so that it could still be passed on as-is, maybe revealed on the logical level later on, and in any case maintained under the strong ACID guarantees that only DBMS's provide -- but as long as it doesn't and you need to be able to abstract away from the structure of some piece of data, circumventing the relational typing machinery can be the least bad alternative.

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