Re: How to model searchable properties of an entity
Date: 19 Aug 2004 04:38:39 -0700
Message-ID: <c0e3f26e.0408190338.288380cc_at_posting.google.com>
"Laconic2" <laconic2_at_comcast.net> wrote in message news:<ybGdnVI2P9IS_77cRVn-jA_at_comcast.com>...
> "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.
Thanks - but in fact I often think the same (well, vice versa!)
> In this case, I think we got an answer from an Object perspective: it has
> to do with the way inheritance works.
<SNIP>
Yes, we have. Mind you, the OP is talking about allowing users to define new product types with new attributes over time, and I don't imagine an OO designer wants the users defining new classes "on the fly" any more than we want the users defining new tables.
> 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."
I love that!
> 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.
> But I'm sure that EAV has a downside, and a real big one.
Yup. And I must admit, maybe I have just been lucky (again) never to have come up against such a requirement. I do remember once in my early days in relational databases seeing a database design for a local government inventory system. It had separate tables called things like street_lamp, post_box, telegraph_pole, etc. etc. I remember saying to a colleague "that's crazy, defining a separate table for each item type". Now I seem to have been advocating that approach here! Actually, I think my inclination now would probably still be more pragmatic: for the most part, all those inventory items can be considered similar: their most important attributes would be stuff like location (grid ref), cost, date installed, date last inspected, make, model, etc. common to all. That data should probably reside in a single table. With a "notes" attribute, there really might not be a need to hold further item-specific information for 80% of the item types. Of course, I am probably over-simplifying drastically here. Received on Thu Aug 19 2004 - 13:38:39 CEST