Re: How to model searchable properties of an entity

"Tony" <andrewst_at_onetel.net.uk> wrote in message news:c0e3f26e.0408180051.2033a4fd_at_posting.google.com...

> I couldn't agree more. And if the issue IS coming from an OO
> perspective, than how is having hundreds of classes and subclasses
> good while hundreds of tables is bad?

Good post Tony. I can't tell you the number of times you've said what I was about to say, only better. I cuts down on the number of responses I post.

In this case, I think we got an answer from an Object perspective: it has to do with the way inheritance works.
In particular, a specialized object really belongs to more than one class. It might belong to the class "parts" and also to the class "pneumatic wheels". A "pneumatic wheel" is just a special class of "part". If we ask what the "unit price" or the "maximum tire pressure" of an object is, it's the object's responsibility to figure out whether to answer the question like a part or like a pneumatic wheel. Therefore the coomplexity doesn't burden the user of the object. That isn't exactly what the object centered opinion said, but it's in the same spirit.

You don't get the same level of detail hiding in a database. That is, not unless you start to use views. You can store data that pertains to all parts, like unit price, in one table. You can store data that pertains only to pneumatic wheels, like maximum tire pressure in another table. And you can provide a view that combines the data together.

But there are objections to that.

>
> I think one possible issue is this requirement to perform queries like
> "select everything that is blue". If we have 1000 different product
> types, and of those 500 have a colour attribute, then either (a) we
> need a supertype table that pulls together either all 1000 product
> types, or just the 500 that have a colour, or (b) we need to UNION
> together 500 tables. Of course, this is only an issue if such queries
> ever make any sense: e.g. maybe someone with a colour-coordinated
> kitchen might want to see all kitchen equipment that comes in blue.

It gets worse. Once a beaureaucracy gets large enough, you get people who operate on the data without a clue as to what it really means. The following dialogue is not invented:

"We shouldn't have sent this guy a letter.  He's a B73."
"What the hell is a B73?"
"I have no idea.  But we never send them any letters."

This really happens. Anybody who never heard an exchange like this has just never worked in a beaureaucratic environment. In cases like this you need to either consult an EAV table, or a view that performs hundreds of unions.

The real problem, for me, is that what I learned, years ago, is to first model the data, and then build the system.

What most people like Dilip want to do, rightly or wrongly, is build the system, and then model the data.

Consider the title of this thread: "How to model searchable properties of an entity". If you build a world wide web first, then want to make everything searchable, the solution is Google. I'm not sure I have a real good soultion in the case at hand.
But I'm sure that EAV has a downside, and a real big one. Received on Wed Aug 18 2004 - 16:09:18 CEST