Re: Modelling objects with variable number of properties in an RDBMS

"VC" <boston103_at_hotmail.com> wrote in message news:P6KdnREFdtrKAfXeRVn-jQ_at_comcast.com...
> I know that, but what recipe does Roy suggest for, let's say, MS SQL
Server
> that does not have either UDTs or other means to implement an entity with
a
> higher than the table limit number of attributes, beyond offering a cute
> saying ?

I didn't think there was any burden on me to solve someone else's specific problem with a specific product. Nor did I think my point needed explaining. I had imagined it was just common sense. Evidently I was mistaken, for which I apologize. Let me explain now:

When we have a pretty good solution with many well-known virtues then it is not sensible to abandon it until we demonstrate that some alternative is actually better than all other conceivable possibilities. Otherwise we are just picking a random alternative with no rational basis on which to prefer it.

For instance, is EAV better than a non-loss decomposition of a 3,000 attribute table into six 500 attribute tables? That is clearly less elegant than the single big table but it at least allows us to continue using SQL and the power of the SQL DBMS. In fact, is EAV better than 3,000 tables each with the key plus another attribute?

These questions and more need to be tested before hoisting EAV onto our shoulders for a heroes welcome. (There is no burden on me to answer them because I am not proposing to use EAV.)

Roy Received on Wed Nov 02 2005 - 14:00:18 CET