Re: Attribute-values in separate table

"Authorised User" <bg_at_microsoft.com> wrote in message news:6t0Ui.4613$CN4.2731_at_news-server.bigpond.net.au...
> On Tue, 04 Sep 2007 00:51:51 -0400, Brian Selzer wrote:

> So, having lots of tables is good from a data-purity point of view... but
> spare a thought for the poor programmer who has to code for each table.
> One general table is far from perfect, and we will lose of a great many
> specific constraints that could help reduce data integrity problems... BUT
> we think we can run with it. In this particular case.

I am not going to rehearse the familiar criticisms of the EAV model all over again. I suspect you've already heard them and done the math and like your answer. I don't, but I don't have to live with it.

What I will say is that once again we see an example of how the database is completely flexible and even crappy present-day SQL implementations can model most of the real world with almost trivial ease, but the application programming is still trapped in about 1965 so we can't exploit it.

So,can we enquire into your example a little more to try to understand what the problem is? It seems to me unlikely that the problem with the many different table definitions is the different business logic associated with the different fact types, because that doesn't go away when you use EAV (in fact it only gets harder to handle). At first glance it looks like the programmers just didn't want to use dynamic SQL, or whatever the equivalent is in their language of choice. Or is it something more fundamental and genuinely intractable?

Roy Received on Thu Oct 25 2007 - 16:30:26 CEST